Stuck Flashing

[mattwilliamson]

Flashing works fine with project0.bin, but when I try to flash with my own program, it gets stuck. I am compiling with Yagarto and when flashing it is stuck after getting the ICDI version. Here's the console log:

matt@wraith:~/Projects/OpenSource/helios$ make -j4

Compiling main.c...
arm-none-eabi-gcc -c -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -Os -ffunction-sections -fdata-sections -MD -std=c99 -Wall -pedantic -c -g -I /Users/matt/Projects/Embedded/Stellaris/StellarisWare/ -DPART_LM4F120H5QR -c -DTARGET_IS_BLIZZARD_RA1 -I/Users/matt/bin/yagarto/yagarto-4.7.1/arm-none-eabi/include/  main.c -o main.o

Compiling startup.c...
arm-none-eabi-gcc -c -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -Os -ffunction-sections -fdata-sections -MD -std=c99 -Wall -pedantic -c -g -I /Users/matt/Projects/Embedded/Stellaris/StellarisWare/ -DPART_LM4F120H5QR -c -DTARGET_IS_BLIZZARD_RA1 -I/Users/matt/bin/yagarto/yagarto-4.7.1/arm-none-eabi/include/  startup.c -o startup.o
Compiling servo.c...
arm-none-eabi-gcc -c -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -Os -ffunction-sections -fdata-sections -MD -std=c99 -Wall -pedantic -c -g -I /Users/matt/Projects/Embedded/Stellaris/StellarisWare/ -DPART_LM4F120H5QR -c -DTARGET_IS_BLIZZARD_RA1 -I/Users/matt/bin/yagarto/yagarto-4.7.1/arm-none-eabi/include/  servo.c -o servo.o
startup.c:13:0: warning: ignoring #pragma DATA_SECTION  [-Wunknown-pragmas]

Making driverlib
make -C /Users/matt/Projects/Embedded/Stellaris/StellarisWare/driverlib/
make[2]: Nothing to be done for `all'.
make[2]: Nothing to be done for `all'.

Linking...
arm-none-eabi-ld -T LM4F.ld --gc-sections -o helios.axf main.o servo.o startup.o /Users/matt/Projects/Embedded/Stellaris/StellarisWare/driverlib/gcc-cm4f/libdriver-cm4f.a /Users/matt/bin/yagarto/yagarto-4.7.1/bin/../lib/gcc/arm-none-eabi/4.7.1/../../../../arm-none-eabi/lib/thumb/v7m/libm.a /Users/matt/bin/yagarto/yagarto-4.7.1/bin/../lib/gcc/arm-none-eabi/4.7.1/../../../../arm-none-eabi/lib/thumb/v7m/libc.a /Users/matt/bin/yagarto/yagarto-4.7.1/bin/../lib/gcc/arm-none-eabi/4.7.1/thumb/v7m/libgcc.a

Copying...
arm-none-eabi-objcopy -Obinary helios.axf helios.bin

Creating list file...
arm-none-eabi-objdump -S helios.axf > helios.lst
matt@wraith:~/Projects/OpenSource/helios$ make load
sudo /Users/matt/Projects/OpenSource/lm4tools/lm4flash/lm4flash helios.bin -v
Found ICDI device with serial: 0E1018F6
ICDI version: 9454
      # !! STUCK HERE !!! CTRL-C
^Cmake: *** [load] Error 130

[mattwilliamson]

This warning worries me a little, it is referencing my interrupt vector table:

startup.c:13:0: warning: ignoring #pragma DATA_SECTION  [-Wunknown-pragmas]

[utzig]

If you would send me the sources by email I could take a look. If you're not allowed to do that please just enable the DEBUG preprocessor macro which is commented out and send me the output of the flasher running.

[mattwilliamson]

Thanks Fabio, I will email you the sources. Thank you very much!

[scompo]

I had a similar problem with my code too, the first time I flash something it works fine, after that it gets stuck. If I power cycle the board the program runs correctly. I used my makefile, startup code and liker file to build the program. The sources are here: https://github.com/scompo/stellaris-launchpad-template-gcc

[utzig]

@scompo Please try again with latest version. Your repo had the very interesting property of building a binary that had the exact size of 1536 which being a multiple of 512 caused the flasher to send a zero sized packet for the ICDI firmware to write. Not sure if this should work but the ICDI hangs when doing that. Now I'm checking for that specific and skipping when this happens.

[scompo]

Well, that's a strange happening!

It works properly with the last pull. The LM4F120H5QR chip used as ICDI doesn't hang so a power cycle of that isn't needed anymore.

My wild guess about this problem it's the firmware for the ICDI chip supposes that a a packet sent should be bigger in size than 0 and it goes into some kind of error routine or stall, blocking itself and the other chip as well in jtag mode.

[mattwilliamson]

haha @scompo I'm using your template to build mine :dancers:

[mattwilliamson]

I updated the startup file to use @scompo's startup file which instead of the #pragma line, it uses __attribute__ ((section(".nvic_table")))

[mattwilliamson]

While flashing with DEBUG I see a similar packet being sent over and over and acked, the last byte changes though:

<<< received 7 bytes
0000 : 2b 24 4f 4b 23 39 61                             +$OK#9a         
>>> sending 537 bytes
0000 : 24 76 46 6c 61 73 68 57 72 69 74 65 3a 30 30 30  $vFlashWrite:000
0010 : 30 31 34 30 30 3a 00 00 00 00 00 00 00 00 00 00  01400:..........
0020 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0030 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0040 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0050 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0060 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0070 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0080 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0090 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00a0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00b0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00c0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00d0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00e0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00f0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0100 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0110 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0120 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0130 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0140 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0150 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0160 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0170 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0180 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0190 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01a0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01b0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01c0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01d0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01e0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01f0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0200 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0210 : 00 00 00 00 00 00 23 36 38                       ......#68   

[utzig]

@mattwilliamson What's the size of your binary file?

[mattwilliamson]

536870914B

On Nov 6, 2012, at 11:31 AM, Fabio Utzig notifications@github.com wrote:

@mattwilliamson What's the size of your binary file?

— Reply to this email directly or view it on GitHub.

[utzig]

@mattwilliamson Well, there's obviously something wrong! :) Flash size on the LM4F120 is 256K and not 512MB! I compiled your code here and got the same size. I'm checking now why this is happening.

[mattwilliamson]

Whoa, I didn't even do the math there. Wowsers! Here's the zip file for my latest: http://dl.dropbox.com/u/14573179/tmp/helios.zip

[utzig]

@mattwilliamson Instead of initialising the global servoPosition to some value, only declare it as global and initialise it on your main() loop. It should look like this:

servo_t *servo; uint16_t servoPosition;

and inside main()

servoPosition = 1000;
while(1) {
    ROM_GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1, GPIO_PIN_1);
    ...

This will fix your problem.

[mattwilliamson]

Wow, that did work. What is the reason behind that?

[utzig]

The problem seems to be with @scompo linker script. His declaration of the data sections looks like this:

.data : AT(ADDR(.text) + SIZEOF(.text))
{   
    _start_data = .;
    *(.data);
    _end_data = .;
} >RAM

The correct way of declaring it should be:

.data :
{
    _start_data = .;
    *(.data);
    _end_data = .;
} >RAM AT >FLASH

So your code was defining the global servoPosition which would go to the .data section and this section had to be written to the binary file to being written to the CPU. But since RAM is at 0x20000000 it was generating a file big enough to write till the first word of RAM.

[utzig]

@mattwilliamson @scompo You should both update your linker scripts. @mattwilliamson You will be able to define global servoPosition = 1000 then.

[mattwilliamson]

Yep, that did it for me. Thank you very very much!

[scompo]

thanks for the info! Sure I will update that and fix also some stuff in the low level code that didn't work properly (eg. .bss to 0). thanks

[utzig]

@scompo I didn't look much into that but I'd pretty sure your startup.c should be doing this:

dest = &_start_bss;
while (dest < &_end_bss) {
    *dest++ = 0;
}

I guess it should use the addresses of _start_bss and _end_bss.

[scompo]

Yep, that's what I figured out debugging it!