crt_emu_cm_redlink problem with multiple sections on the same page

lpcware · ‎06-15-2016

Content originally posted in LPCWare by marcocenerelli on Fri Jan 15 11:15:46 MST 2016
Hello, I'm using LPCXpresso v8.0.0_526 on Linux. The command-line tool crt_emu_cm_redlink has a problem with ELFs with multiple sections on the same SPI flash page (MCU is an LPC1830). The tool erases each time the same flash page, it doesn't matter if you launch it with -flash-mass-load or with -flash-load. This is the command line output:

Ni: LPCXpresso RedlinkMulti Driver v7.9 (Jul 23 2015 14:20:59 - crt_emu_cm_redlink build 468)
Pc: (  0) Reading remote configuration
Pc: (  5) Remote configuration complete
Nc: Probe Firmware: LPC-LINK2 CMSIS-DAP V5.134 (NXP Semiconductors)
Nc: VID:PID:  1FC9:0090
Nc: USB Path: /dev/hidraw4
Pc: ( 30) Emulator Connected
Pc: ( 40) Debug Halt
Pc: ( 50) CPU ID
Nc: Emu(0): Connected&Reset. DpID: 2BA01477. CpuID: 410FC230. Info: <None>
Nc: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Nc: loaded v.2 External Flash Device on SPI Flash/LPC18_43_SPIFI_GENERIC.cfx
Nc: image 'LPC18/43 Generic SPIFI Nov  2 2015 16:52:43'
Nc: flash variant 'S25FL064P' detected (8MB = 128*64K at 0x14000000)
Pc: ( 65) Chip Setup Complete
Nt: Connected: was_reset=false. was_stopped=true
Cf:v LPCXpressoPro Full License - Unlimited
Pc: ( 70) License Check Complete
Nt: Loading ELF file 'Bootloader.axf' at location 14000000
Ec: Flash Driver V.2 dynamic startup ignored - driver Init provided no info in STATUS

Nt: Writing 1376 bytes to address 0x14000000 in Flash
Pb: 1 of 1 (  0) Writing pages 0-0 at 0x14000000 with 1376 bytes
Ps: (  0) at 14000000: 0 bytes - 0/1376
Ps: (1190) at 14000000: 16384 bytes - 16384/1376
Nc: Progress meter completed at over 100% (16384/1376 bytes)
Nt: Erased/Wrote page  0-0 with 1376 bytes in 314msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x560 bytes in 517ms (about 2kB/s)
Nt: Loading ELF file 'Bootloader.axf' at location 14000674
Nt: Writing 25880 bytes to address 0x14000674 in Flash
Pb: 1 of 1 (  0) Writing pages 0-0 at 0x14000674 with 25880 bytes
Ps: (  0) at 14000000: 0 bytes - 0/27532
Ps: ( 59) at 14000000: 16384 bytes - 16384/27532
Ps: (119) at 14004000: 16384 bytes - 32768/27532
Nc: Progress meter completed at over 100% (32768/27532 bytes)
Nt: Erased/Wrote page  0-0 with 25880 bytes in 454msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x6518 bytes in 677ms (about 38kB/s)
Nt: Loading ELF file 'Bootloader.axf' at location 14000560
Ec: Flash Driver V.2 dynamic startup ignored - driver Init provided no info in STATUS

Nt: Writing 276 bytes to address 0x14000560 in Flash
Pb: 1 of 1 (  0) Writing pages 0-0 at 0x14000560 with 276 bytes
Ps: (  0) at 14000000: 0 bytes - 0/1652
Ps: (991) at 14000000: 16384 bytes - 16384/1652
Nc: Progress meter completed at over 100% (16384/1652 bytes)
Nt: Erased/Wrote page  0-0 with 276 bytes in 320msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x114 bytes in 522ms (about 0kB/s)
Nt: Loading ELF file 'Bootloader.axf' at location 14010000
Nt: Writing 196608 bytes to address 0x14010000 in Flash
Pb: 1 of 1 (  0) Writing pages 1-3 at 0x14010000 with 196608 bytes
Ps: (  0) at 14010000: 0 bytes - 0/196608
Ps: (  8) at 14010000: 16384 bytes - 16384/196608
Ps: ( 16) at 14014000: 16384 bytes - 32768/196608
Ps: ( 25) at 14018000: 16384 bytes - 49152/196608
Ps: ( 33) at 1401C000: 16384 bytes - 65536/196608
Ps: ( 41) at 14020000: 16384 bytes - 81920/196608
Ps: ( 50) at 14024000: 16384 bytes - 98304/196608
Ps: ( 58) at 14028000: 16384 bytes - 114688/196608
Ps: ( 66) at 1402C000: 16384 bytes - 131072/196608
Ps: ( 75) at 14030000: 16384 bytes - 147456/196608
Ps: ( 83) at 14034000: 16384 bytes - 163840/196608
Ps: ( 91) at 14038000: 16384 bytes - 180224/196608
Ps: (100) at 1403C000: 16384 bytes - 196608/196608
Nt: Erased/Wrote page  1-3 with 196608 bytes in 2464msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x30000 bytes in 2688ms (about 73kB/s)

The correct behavior should be:
1) erase all needed sectors
2) program all sectors

Please fix it as soon as possible.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by marcocenerelli on Wed Jan 20 07:48:04 MST 2016

Quote: lpcxpresso-support
If your image is failing to correctly program (which we would still like to know?), then you could try the following as a workaround:

1) Create a file called, say prog.txt, in the top level of your project directory.

2) Add the following contents to prog.txt:

set remotetimeout 60000
target extended-remote | crt_emu_cm_redlink -2 -vendor=NXP -pLPC1830 -wire=redlink  -ResetScript=LPC18LPC43ExternalFLASHBootResetscript.scp -x ./Debug
load
quit

3) Now to program your flash without starting a full debug session, right click on your project in the Project Explorer view and select:

Utilities -> Open command prompt here

4) The command prompt opened in this way will have the path to the tools set up in it. Execute the following command:

arm-none-eabi-gdb ./Debug/Test.axf -x prog.txt

and your flash should get programmed with gdb pre-parsing the file so that the sections from the ELF file are programmed as you expect.

Note that this does assume that you have already booted your LPC-Link2 (or have pre-programmed the CMSIS-DAP firmware into its flash using LPCScrypt).

Regards,
LPCXpresso Support

Sorry for sounding rude, but I explained more than once that loading with the external tool is not working because the image is not loaded correctly and I keep being asked the same questions. It's clear that the behaviour of the tool is not correct, how can you justify that the flash gets mass erased more than once? It's also obvious that the firmware is not starting as there is nothing at 0x14000000 because the relevant ELF section has been erased. Just to be even more clear, I will say it explicitly, the LED is not blinking, ok?

Anyway, as I said before, with GDB loading is correctly done. The correct command is this (the one you supplied is wrong):

target extended-remote | crt_emu_cm_redlink -2 -vendor=NXP -pLPC1830 -wire=redlink -flash-driver=LPC18_43_SPIFI_GENERIC.cfx -ResetScript=LPC18LPC43ExternalFLASHBootResetscript.scp -x ./Debug

output:

Ni: LPCXpresso RedlinkMulti Driver v8.0 (Nov 17 2015 10:18:17 - crt_emu_cm_redlink build 556)
Nc: Found chip XML file in ./Debug/LPC1830.xml

Nc: Probe Firmware: LPC-LINK2 CMSIS-DAP V5.134 (NXP Semiconductors)
Nc: VID:PID:  1FC9:0090
Nc: USB Path: /dev/hidraw5
Pc: ( 30) Emulator Connected
Pc: ( 40) Debug Halt
Pc: ( 50) CPU ID
Nc: Emu(0): Connected&Reset. DpID: 2BA01477. CpuID: 410FC230. Info: <None>
Nc: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Nc: loaded v.2 External Flash Device on SPI /home/marco/lpcxpresso_8.0.0_526/lpcxpresso/bin/Flash/LPC18_43_SPIFI_GENERIC.cfx
Nc: image 'LPC18/43 Generic SPIFI Nov  2 2015 16:52:43'
Nc: flash variant 'S25FL064P' detected (8MB = 128*64K at 0x14000000)
Nc: NXP: LPC1830  Part ID: 0x0880467C
Nt: Connected: was_reset=false. was_stopped=true
Cf:v LPCXpressoPro Full License - Unlimited
0x10000050 in test_function () at ../src/Test.c:37
37for (i = 0; i < 5000000; i++) {
Loading section .text, size 0x428 lma 0x14000000
Loading section .data_RAM2, size 0x2000 lma 0x14000428
Loading section .data, size 0x60a0 lma 0x14002428
Loading section .text_Flash2, size 0x20000 lma 0x14010000
Ec: Flash Driver V.2 dynamic startup ignored - driver Init provided no info in STATUS

Nt: Writing 33992 bytes to address 0x14000000 in Flash
Nt: Erased/Wrote page  0-0 with 33992 bytes in 586msec
Nt: Flash Write Done
Nt: Writing 131072 bytes to address 0x14010000 in Flash
Nt: Erased/Wrote page  1-2 with 131072 bytes in 1628msec
Nt: Flash Write Done
Nt: Flash Program Summary: 165064 bytes in 2.21 seconds (72.81 KB/sec)
Wc: ============= SCRIPT: LPC18LPC43ExternalFLASHBootResetscript.scp =============
Wc: Boot from FLASH image pc/sp reset script
Wc: PC = 0x14000301
Wc: SP = 0x10018000
Wc: XPSR = 0x01000000
Wc: VTOR = 0x00000000
Wc: ============= END SCRIPT =====================================================
Nt: 
Start address 0x14000300, load size 165064
Transfer rate: 59 KB/sec, 12697 bytes/write.
A debugging session is active.

Inferior 1 [Remote target] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

As you can easily see, only two flash sectors are erased, regardless of how many ELF sections need to be loaded. This is what your tool must do in standalone mode.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Jan 20 07:24:47 MST 2016
If your image is failing to correctly program (which we would still like to know?), then you could try the following as a workaround:

1) Create a file called, say prog.txt, in the top level of your project directory.

2) Add the following contents to prog.txt:

set remotetimeout 60000
target extended-remote | crt_emu_cm_redlink -2 -vendor=NXP -pLPC1830 -wire=redlink  -ResetScript=LPC18LPC43ExternalFLASHBootResetscript.scp -x ./Debug
load
quit

3) Now to program your flash without starting a full debug session, right click on your project in the Project Explorer view and select:

Utilities -> Open command prompt here

4) The command prompt opened in this way will have the path to the tools set up in it. Execute the following command:

arm-none-eabi-gdb ./Debug/Test.axf -x prog.txt

and your flash should get programmed with gdb pre-parsing the file so that the sections from the ELF file are programmed as you expect.

Note that this does assume that you have already booted your LPC-Link2 (or have pre-programmed the CMSIS-DAP firmware into its flash using LPCScrypt).

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Jan 20 06:19:08 MST 2016
I appreciate that you are telling me how you think the tool ought to work based on your assessment of what you see in the log.

But if you can please just answer my question, we will then be able to determine how we actually move forward with handling your request.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by marcocenerelli on Wed Jan 20 06:11:25 MST 2016

Quote: lpcxpresso-support
You have missed the point here : the tool should cope with the fact that part of the sector was already written when it rewrites. I am trying to determine if this is working in your exact setup. Or if you just complaining that what you see in the log does not seem sensible.

So for the moment please ignore how the tool is programming the flash (rewrites/reerases) and the output that is generated in the log and just confirm - does your application actually function after it has been programmed?

Regards,
LPCXpresso Support

Sorry, but I think that you are actually missing the point. The behaviour is the following:

1) erase flash sector 0
2) program ELF section (Nt: Loading 'Test.axf' ELF sect 1 0x14000000 len 0x428)
3) erase flash sector 0
4) program ELF section (Nt: Loading 'Test.axf' ELF sect 0 0x14002428 len 0x60A0)
5) erase flash sector 0
6) program ELF section (Nt: Loading 'Test.axf' ELF sect 1 0x14000428 len 0x2000)
7) erase flash sector 1

program ELF section (Nt: Loading 'Test.axf' ELF sect 2 0x14010000 len 0x20000)

Do you really think that it is possible that it can work in this condition? Are you realizing that the only section loaded on the flash is the third one and that the other two have been erased?
As I already stated, your tool is doing this:

foreach (ELF section)
    erase flash sector(s)
    program flash sector(s)
end

The exact same behaviour happens if you choose to do mass erase, the tool will do mass erase multiple times. This is completely wrong, the tool must read in advance what are the flash sectors to be erased, erase them all at once and them program the ELF sections one by one.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Jan 20 05:45:14 MST 2016
You have missed the point here : the tool should cope with the fact that part of the sector was already written when it rewrites. I am trying to determine if this is working in your exact setup. Or if you just complaining that what you see in the log does not seem sensible.

So for the moment please ignore how the tool is programming the flash (rewrites/reerases) and the output that is generated in the log and just confirm - does your application actually function after it has been programmed?

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by marcocenerelli on Wed Jan 20 03:58:13 MST 2016

Quote: lpcxpresso-support
Can you just confirm - on your board, does the code actually run correctly after programming (regardless of the order that crt_emu_cm_redlink programs the sections from the ELF file)?

Generally we would expect programming to succeed even in cases where "rewrites" to the same flash sector take place.

Regards,
LPCXpresso Support

Of course it doesn't work, it erases the sectors that it already programmed. The problem is not rewriting, the problem is reerasing.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Jan 20 01:11:33 MST 2016
Can you just confirm - on your board, does the code actually run correctly after programming (regardless of the order that crt_emu_cm_redlink programs the sections from the ELF file)?

Generally we would expect programming to succeed even in cases where "rewrites" to the same flash sector take place.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by marcocenerelli on Tue Jan 19 04:16:08 MST 2016

Quote: lpcxpresso-support
The issue you are seeing is being triggered by the order that the generated linker script is creating the sections in the outputed ELF file, in particular the fact the more than 1 of the .data* sections has initialised values being placed into it.

Whilst we investigate in more detail this interaction between your generated ELF file and the command line flash programmer, if you use the attached Freemarker linker script template file (putting the extracted .ldt file into your linkscripts subdirectory), then I think the problem will be avoided.

Please let us know how you get on with this.

Regards,
LPCXpresso Support

Tried it, didn't work.

Ni: LPCXpresso RedlinkMulti Driver v8.0 (Nov 17 2015 10:18:17 - crt_emu_cm_redlink build 556)
Pc: (  0) Reading remote configuration
Nc: Found chip XML file in /home/marco/LPCXpresso/workspace3/Test/Debug//LPC1830.xml

Pc: (  5) Remote configuration complete
Nc: Probe Firmware: LPC-LINK2 CMSIS-DAP V5.134 (NXP Semiconductors)
Nc: VID:PID:  1FC9:0090
Nc: USB Path: /dev/hidraw6
Pc: ( 30) Emulator Connected
Pc: ( 40) Debug Halt
Pc: ( 50) CPU ID
Nc: Emu(0): Connected&Reset. DpID: 2BA01477. CpuID: 410FC230. Info: <None>
Nc: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Nc: loaded v.2 External Flash Device on SPI Flash/LPC18_43_SPIFI_GENERIC.cfx
Nc: image 'LPC18/43 Generic SPIFI Nov  2 2015 16:52:43'
Nc: flash variant 'S25FL064P' detected (8MB = 128*64K at 0x14000000)
Nc: NXP: LPC1830  Part ID: 0x08EB165C
Pc: ( 65) Chip Setup Complete
Nt: Connected: was_reset=false. was_stopped=false
Cf:v LPCXpressoPro Full License - Unlimited
Pc: ( 70) License Check Complete
Nt: Loading 'Test.axf' ELF sect 1 0x14000000 len 0x428
Nt: Writing 1064 bytes to address 0x14000000 in Flash
Pb: 1 of 1 (  0) Writing pages 0-0 at 0x14000000 with 1064 bytes
Ps: (  0) at 14000000: 0 bytes - 0/1064
Ps: (100) at 14000000: 16384 bytes - 16384/1064
Nt: Erased/Wrote page  0-0 with 1064 bytes in 332msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x428 bytes in 553ms (about 1kB/s)
Nt: Loading 'Test.axf' ELF sect 0 0x14002428 len 0x60A0
Nt: Writing 24736 bytes to address 0x14002428 in Flash
Pb: 1 of 1 (  0) Writing pages 0-0 at 0x14002428 with 24736 bytes
Ps: (  0) at 14000000: 0 bytes - 0/33992
Ps: ( 48) at 14000000: 16384 bytes - 16384/33992
Ps: ( 96) at 14004000: 16384 bytes - 32768/33992
Ps: (100) at 14008000: 16384 bytes - 49152/33992
Nt: Erased/Wrote page  0-0 with 24736 bytes in 644msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x60A0 bytes in 866ms (about 28kB/s)
Nt: Loading 'Test.axf' ELF sect 1 0x14000428 len 0x2000
Nt: Writing 8192 bytes to address 0x14000428 in Flash
Pb: 1 of 1 (  0) Writing pages 0-0 at 0x14000428 with 8192 bytes
Ps: (  0) at 14000000: 0 bytes - 0/9256
Ps: (100) at 14000000: 16384 bytes - 16384/9256
Nt: Erased/Wrote page  0-0 with 8192 bytes in 354msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x2000 bytes in 585ms (about 14kB/s)
Nt: Loading 'Test.axf' ELF sect 2 0x14010000 len 0x20000
Nt: Writing 131072 bytes to address 0x14010000 in Flash
Pb: 1 of 1 (  0) Writing pages 1-2 at 0x14010000 with 131072 bytes
Ps: (  0) at 14010000: 0 bytes - 0/131072
Ps: ( 12) at 14010000: 16384 bytes - 16384/131072
Ps: ( 25) at 14014000: 16384 bytes - 32768/131072
Ps: ( 37) at 14018000: 16384 bytes - 49152/131072
Ps: ( 50) at 1401C000: 16384 bytes - 65536/131072
Ps: ( 62) at 14020000: 16384 bytes - 81920/131072
Ps: ( 75) at 14024000: 16384 bytes - 98304/131072
Ps: ( 87) at 14028000: 16384 bytes - 114688/131072
Ps: (100) at 1402C000: 16384 bytes - 131072/131072
Nt: Erased/Wrote page  1-2 with 131072 bytes in 1628msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x20000 bytes in 1848ms (about 70kB/s)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by marcocenerelli on Tue Jan 19 04:11:39 MST 2016

Quote: lpcxpresso-support
One additional point to my previous post ...

If you convert the AXF to binary, can you successfully flash program that?
https://www.lpcware.com/content/faq/lpcxpresso/generating-srec-binary-and-ihex-files

Note that you will need to specify the base address of the image when you program the binary rather than the AXF.

Regards,
LPCXpresso Support

If I convert it to hex it works as previously stated, converting it to binary yields a wrong bin file, it should be possible in theory to place sections manually in the bin file but hex was faster in the end.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by marcocenerelli on Tue Jan 19 04:10:20 MST 2016
Hello, I did it on another machine and forgot that it didn't have the latest IDE. Log for 8.0.0 shows the same behavior:

Ni: LPCXpresso RedlinkMulti Driver v8.0 (Nov 17 2015 10:18:17 - crt_emu_cm_redlink build 556)
Pc: ( 0) Reading remote configuration
Nc: Found chip XML file in /home/marco/LPCXpresso/workspace3/Test/Debug//LPC1830.xml

Pc: ( 5) Remote configuration complete
Nc: Probe Firmware: LPC-LINK2 CMSIS-DAP V5.134 (NXP Semiconductors)
Nc: VID:PID: 1FC9:0090
Nc: USB Path: /dev/hidraw6
Pc: ( 30) Emulator Connected
Pc: ( 40) Debug Halt
Pc: ( 50) CPU ID
Nc: Emu(0): Connected&Reset. DpID: 2BA01477. CpuID: 410FC230. Info: <None>
Nc: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Nc: loaded v.2 External Flash Device on SPI Flash/LPC18_43_SPIFI_GENERIC.cfx
Nc: image 'LPC18/43 Generic SPIFI Nov 2 2015 16:52:43'
Nc: flash variant 'S25FL064P' detected (8MB = 128*64K at 0x14000000)
Nc: NXP: LPC1830 Part ID: 0x0953665C
Pc: ( 65) Chip Setup Complete
Nt: Connected: was_reset=false. was_stopped=true
Cf:v LPCXpressoPro Full License - Unlimited
Pc: ( 70) License Check Complete
Nt: Loading 'Test.axf' ELF sect 1 0x14000000 len 0x428
Nt: Writing 1064 bytes to address 0x14000000 in Flash
Pb: 1 of 1 ( 0) Writing pages 0-0 at 0x14000000 with 1064 bytes
Ps: ( 0) at 14000000: 0 bytes - 0/1064
Ps: (100) at 14000000: 16384 bytes - 16384/1064
Nt: Erased/Wrote page 0-0 with 1064 bytes in 332msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x428 bytes in 563ms (about 1kB/s)
Nt: Loading 'Test.axf' ELF sect 0 0x14002428 len 0x60A0
Nt: Writing 24736 bytes to address 0x14002428 in Flash
Pb: 1 of 1 ( 0) Writing pages 0-0 at 0x14002428 with 24736 bytes
Ps: ( 0) at 14000000: 0 bytes - 0/33992
Ps: ( 48) at 14000000: 16384 bytes - 16384/33992
Ps: ( 96) at 14004000: 16384 bytes - 32768/33992
Ps: (100) at 14008000: 16384 bytes - 49152/33992
Nt: Erased/Wrote page 0-0 with 24736 bytes in 645msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x60A0 bytes in 866ms (about 28kB/s)
Nt: Loading 'Test.axf' ELF sect 1 0x14000428 len 0x2000
Nt: Writing 8192 bytes to address 0x14000428 in Flash
Pb: 1 of 1 ( 0) Writing pages 0-0 at 0x14000428 with 8192 bytes
Ps: ( 0) at 14000000: 0 bytes - 0/9256
Ps: (100) at 14000000: 16384 bytes - 16384/9256
Nt: Erased/Wrote page 0-0 with 8192 bytes in 355msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x2000 bytes in 576ms (about 14kB/s)
Nt: Loading 'Test.axf' ELF sect 2 0x14010000 len 0x20000
Nt: Writing 131072 bytes to address 0x14010000 in Flash
Pb: 1 of 1 ( 0) Writing pages 1-2 at 0x14010000 with 131072 bytes
Ps: ( 0) at 14010000: 0 bytes - 0/131072
Ps: ( 12) at 14010000: 16384 bytes - 16384/131072
Ps: ( 25) at 14014000: 16384 bytes - 32768/131072
Ps: ( 37) at 14018000: 16384 bytes - 49152/131072
Ps: ( 50) at 1401C000: 16384 bytes - 65536/131072
Ps: ( 62) at 14020000: 16384 bytes - 81920/131072
Ps: ( 75) at 14024000: 16384 bytes - 98304/131072
Ps: ( 87) at 14028000: 16384 bytes - 114688/131072
Ps: (100) at 1402C000: 16384 bytes - 131072/131072
Nt: Erased/Wrote page 1-2 with 131072 bytes in 1683msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x20000 bytes in 1912ms (about 68kB/s)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Tue Jan 19 02:58:11 MST 2016
The issue you are seeing is being triggered by the order that the generated linker script is creating the sections in the outputed ELF file, in particular the fact the more than 1 of the .data* sections has initialised values being placed into it.

Whilst we investigate in more detail this interaction between your generated ELF file and the command line flash programmer, if you use the attached Freemarker linker script template file (putting the extracted .ldt file into your linkscripts subdirectory), then I think the problem will be avoided.

Please let us know how you get on with this.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Mon Jan 18 06:35:37 MST 2016
One additional point to my previous post ...

If you convert the AXF to binary, can you successfully flash program that?
https://www.lpcware.com/content/faq/lpcxpresso/generating-srec-binary-and-ihex-files

Note that you will need to specify the base address of the image when you program the binary rather than the AXF.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Mon Jan 18 05:17:28 MST 2016
Can you also confirm what version of LPCXpresso IDE you are actually seeing problems with? Your initial report was against LPCXpresso IDE v8.0, but your logs appear to show the command line flash programming tool from LPCXpresso IDE v7.9.2 being used.

This is quite important for investigating any issues, as the underlying flash programming code underwent some major revamps in v8.0 to support multiple flash drivers:

https://www.lpcware.com/content/faq/lpcxpresso/configuring-projects-multiple-flash
https://www.lpcware.com/content/forum/lpcxpresso-latest-release

Note that we would expect to see some level of flash writes/rewrites when you scatter elements throughout a sector. But the debug stub executable should cope with doing this. I assume that in your case, your blinky application doesn't blink after resetting the board following the use of the command line flash programmer?

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by marcocenerelli on Mon Jan 18 04:42:32 MST 2016
Hello, attached is the test project. It only toggles an LED on our board but it's of course enough for you to see the issue. Following is the output of the command-line tool:

./crt_emu_cm_redlink -g -4 -p LPC1830 -flash-driver Flash/LPC18_43_SPIFI_GENERIC.cfx -flash-load ~/LPCXpresso/workspace3/Test/Debug/Test.axf
Ni: LPCXpresso RedlinkMulti Driver v7.9 (Jul 23 2015 14:20:59 - crt_emu_cm_redlink build 468)
Pc: (  0) Reading remote configuration
Pc: (  5) Remote configuration complete
Nc: Probe Firmware: LPC-LINK2 CMSIS-DAP V5.134 (NXP Semiconductors)
Nc: VID:PID:  1FC9:0090
Nc: USB Path: /dev/hidraw1
Pc: ( 30) Emulator Connected
Pc: ( 40) Debug Halt
Pc: ( 50) CPU ID
Nc: Emu(0): Connected&Reset. DpID: 2BA01477. CpuID: 410FC230. Info: <None>
Nc: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Nc: loaded v.2 External Flash Device on SPI Flash/LPC18_43_SPIFI_GENERIC.cfx
Nc: image 'LPC18/43 Generic SPIFI Nov  2 2015 16:52:43'
Nc: flash variant 'S25FL064P' detected (8MB = 128*64K at 0x14000000)
Pc: ( 65) Chip Setup Complete
Nt: Connected: was_reset=false. was_stopped=false
Cf:v LPCXpressoPro Full License - Unlimited
Pc: ( 70) License Check Complete
Nt: Loading ELF file 'Test.axf' at location 14000000
Nt: Writing 1064 bytes to address 0x14000000 in Flash
Pb: 1 of 1 (  0) Writing pages 0-0 at 0x14000000 with 1064 bytes
Ps: (  0) at 14000000: 0 bytes - 0/1064
Ps: (1539) at 14000000: 16384 bytes - 16384/1064
Nc: Progress meter completed at over 100% (16384/1064 bytes)
Nt: Erased/Wrote page  0-0 with 1064 bytes in 336msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x428 bytes in 588ms (about 1kB/s)
Nt: Loading ELF file 'Test.axf' at location 14002428
Nt: Writing 24736 bytes to address 0x14002428 in Flash
Pb: 1 of 1 (  0) Writing pages 0-0 at 0x14002428 with 24736 bytes
Ps: (  0) at 14000000: 0 bytes - 0/33992
Ps: ( 48) at 14000000: 16384 bytes - 16384/33992
Ps: ( 96) at 14004000: 16384 bytes - 32768/33992
Ps: (144) at 14008000: 16384 bytes - 49152/33992
Nc: Progress meter completed at over 100% (49152/33992 bytes)
Nt: Erased/Wrote page  0-0 with 24736 bytes in 653msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x60A0 bytes in 912ms (about 27kB/s)
Nt: Loading ELF file 'Test.axf' at location 14000428
Nt: Writing 8192 bytes to address 0x14000428 in Flash
Pb: 1 of 1 (  0) Writing pages 0-0 at 0x14000428 with 8192 bytes
Ps: (  0) at 14000000: 0 bytes - 0/9256
Ps: (177) at 14000000: 16384 bytes - 16384/9256
Nc: Progress meter completed at over 100% (16384/9256 bytes)
Nt: Erased/Wrote page  0-0 with 8192 bytes in 354msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x2000 bytes in 610ms (about 13kB/s)
Nt: Loading ELF file 'Test.axf' at location 14010000
Nt: Writing 131072 bytes to address 0x14010000 in Flash
Pb: 1 of 1 (  0) Writing pages 1-2 at 0x14010000 with 131072 bytes
Ps: (  0) at 14010000: 0 bytes - 0/131072
Ps: ( 12) at 14010000: 16384 bytes - 16384/131072
Ps: ( 25) at 14014000: 16384 bytes - 32768/131072
Ps: ( 37) at 14018000: 16384 bytes - 49152/131072
Ps: ( 50) at 1401C000: 16384 bytes - 65536/131072
Ps: ( 62) at 14020000: 16384 bytes - 81920/131072
Ps: ( 75) at 14024000: 16384 bytes - 98304/131072
Ps: ( 87) at 14028000: 16384 bytes - 114688/131072
Ps: (100) at 1402C000: 16384 bytes - 131072/131072
Nt: Erased/Wrote page  1-2 with 131072 bytes in 1657msec
Pb: (100) Finished writing Flash successfully.
Nt: Flash Write Done
Nt: Loaded 0x20000 bytes in 1914ms (about 68kB/s)

Loading with the GDB works correctly.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Mon Jan 18 02:15:23 MST 2016
As already requested, please post at least an.axf file, and preferably your project settings and map file.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by marcocenerelli on Sat Jan 16 00:26:47 MST 2016
Hello,

as I stated in my post, I'm not using GDB to load the flash image, I'm using the command-line tool, with GDB the flash is loaded correctly. The tool has the possibility to read the sections in the ELF file and understand which SPI flash sectors have to be erased, then it has to erase each sector *before* downloading the code. Your tool is doing this:

foreach(section in ELF file)
    erase memory sector
    program flash
end

while it should do this

foreach(section in ELF file)
    erase memory sector
end
foreach(section in ELF file)
    program flash
end

The behavior can be simply demonstrated by loading a project which places some variables, functions or libraries in RAM. This will make the linker create contiguous sections, e.g.
TEXT area 0x14000000 size 1300 bytes
TEXT area 0x14000514 size 20000 bytes
...

In this condition your tool will erase sector 0 (0x14000000) twice and the first TEXT area will be erased.

GDB is already handling this correctly, so I believe the bug is only in the standalone tool. Creating an IHEX from the ELF and loading it with other tools (JFlash) works correctly of course.

[EDIT] Also, it's even more clear that it's a bug because if you do mass-erase the tool will do:
mass-erase
load section 0
mass-erase
load section 1
mass-erase
load section 2
...

Thanks for the support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Fri Jan 15 15:26:20 MST 2016

Hi Marco,

First, you should attach at least an.axf file for us to investigate, and preferably your project settings and map file. The behavior you describe happens when GDB splits the flash image before sending it to the debug utility to program.This is typically a result of non-contiguous sections (e.g. section alignment, etc.). In other words, an address gap exists between the end of one section, and the start of the next. In this case, GDB sends separate flash program messages. The debug utility has no way to know whether it's the last image it's going to get, so it has to program what it has. If another flash program message arrives and the start address is offset within the sector, the data from the sector start has to be cached, the sector erased, and then reprogrammed with old/new data. Note you can use the FILL linker command to ensure there is no gaps in the image.

Thanks and regards,
LPCXpresso Support