• View
• Edit
• History
• Print

HailSize

This page consists of notes about TockOS problems with the Hail board and size

Too Big

The first problem is that make fails because the file is too big:

The size of the SRAM is determined by https://github.com/helena-project/tock/blob/master/userland/linker.ld :

See Duktape under Cortex M4: region `SRAM' overflowed by 36208 bytes (Google Groups) for possibilities about relocating.

However, smaller sizes are possible:

• 512K of memory so that we have breathing room. 256K might not work. Duktape Eclipse ARM Cortex M4 was reported to have the following sizes:
  • Code size = 176K
  • Constants = 628 bytes
  • RAM = 492 bytes

Here are the sizes:

See https://mcuoneclipse.com/2013/04/14/text-data-and-bss-code-and-data-size-explained/ for an explanation about text, data and bss.

We want to decrease data by moving the the JavaScript code that is encoded in the .h files into the text segment.

To do this, we make the arrays in commonHost.h, events.h and util.h be const.

Compilation

See Compilation for details

RampJSDisplay

It is possible to read from stdout using tockloader

eduk.c was modifies so that if it is compiled with -DEDUK_RAMPJSDISPLAY -DEDUK_RUNRAMPJSDISPLAY, then the test/auto/RampJSDisplay.js Composite Accessor is invoked.

Below is a run of eduk from a shell. Note that we used Control-C to terminate.

RESPONSE_BADADDR: Invalid address for page to write

Unfortunately, the binary is still too large and fails to flash:

Here's the size of our duktape binary compared with the accl-leds binary.

See Duktape under Cortex M4: region `SRAM' overflowed by 36208 bytes (Google Groups) for possibilities about relocating.

Minimum Duktape

I added a #ifdef EDUK_MIN to try to create the a very small eduk:

But it failed:

The above message comes from https://github.com/helena-project/tockloader/blob/master/tockloader/main.py

The Hail boot loader at https://github.com/lab11/hail/blob/master/bootloader/src/bl_commands.c is what returns the RESPONSE_BADARGS. (Note that in tockloader, the macro is RESPONSE_BADARGS, whereas in bootloader, it is RES_BADARGS.

Optimize for space

Using -Os to optimize for space failed:

Interestingly compiling accel-leds with -Os works.

Without -Os:

With -Os:

Eventually, I was able to get tockloader to work.

Adding a print statement to /opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/tockloader/main.py seemed to allow the load to complete?

Tockloader

Below is an approved way of updated tockloader.

Local TockLoader

Messing around with tockloader was getting tricky because when I installed using /opt/local/bin/pip-3.6, the main.py was owned by root.

Then, when in downloaded from the tockloader github repo and ran setup, it looked like /opt/local/Library/Frameworks/Python.framework/Versions/3.6/bin/tockloader was using a compressed .egg file.

So, I installed a local copy.

Continuing with Optimizing for Space

After getting -Os to work and tockloader working, I can upload

However, the red LED flashes, indicating a problem.

Using tockloader listen, I see the following output:

Update my fork

See Updating my fork for how to merge from the helena-project/tock repo into the branch

I then reprogrammed the kernel on the board, see https://github.com/helena-project/tock/tree/master/boards/hail

Size Again

The new version has better error map, below is how to reproduce the issue

I have ifdef'd my main down to just printing, which works fine, I can listen to the board and see the message.

However, if at link time, I include the duktape.o file, then I get a fault.

I'm guessing this is a size issue, but could use some help.

Details:

Here's how to reproduce this.

I'm using these versions:

I'm working in a branch (cxbrooks/ducktape3) on a (fork https://github.com/cxbrooks/tock). I sync'd my fork to the helena-project/tock about 60 minutes ago:

Here are the commands to run:

The blink program works fine.

The duktape example program consists of a makefile that has a target called "update" that checks out the accessors repo and copies .c and .h files.

Here are the sizes:

The board has the red-blink-of-death.

(Reminds me of the students that used a red blinking LED as their first program on a similar board. They thought they got it right the first time! But it was just the error blink.)

Listening to the port:

BTW - the output is pretty, but it does not copy and paste that well. Maybe stick with non-graphical characters?

Ok, so the above failed.

Now remove duktape.c, which is huge, and two files that use functions defined in duktape.c:

Here are the sizes:

And here is my message:

So, printing works. Below is the part of the main() from eduk.c:

So, what I don't understand is why including duktape.o in the binary is causing the crash. Any ideas?

Unfortunately, duktape.c is 87k lines of code, so paring this down is not easy.

I'm using Duktape-1.6.0, which came out in December. Duktape-2.0.0 is out, but the configuration options have changed.

I have not looked very far in to how to use gdb to debug this. I was able to use tools/build-arm-gdb to build an arm-specific version of gdb. I believe I need to use the -tty argument to gdb. I see that https://github.com/helena-project/tock/blob/master/doc/tutorials/README.md has plans for a JTAG/GDB tutorial and that https://github.com/helena-project/tock/blob/master/boards/storm/README.md has some details about using JLinkGDBServer. My guess is that to use gdb, I need to get a JTAG box. I saw some notes about which JTAG box is preferred, but I'm not finding them right now.

So, any ideas here?

Disable the MPU

Below is Brendan's response:

See Duktape2 Initial Compilation