Hello!
I am using codewarrior and TWR-60 evalatuin board and its USB interface for debugging. I have two projects.
1. Very simple bootloader that shall jump to main app.
2. Main app, located at flash 0xC000 (exception vectors starts here). I have modified the linker files accordingly.
I used the following information as reference Modify linker command files
First I erase the whole flash and program the bootloader, no problems there, it takes a couple of sec.
Then I try to flash the main app with modified debugger advanced settings to preserve NVM area 0x0 to 0xBFFF.
Once started it takes minutes for the debugger to finish. It halts here (taken from console)
...
INF: ;begin_cs device=$00000000, length=$00080000, ram=$20000000
INF: Loading programming algorithm ...
INF: WARNING - Selected .ARP file has been modified. CRC16 = $347F
INF: Done.
INF: CMD>EM
Then it takes a couple of minutes for the debugger to continue with erasing, programming etc. I have noticed that if I reduce the preserved mem range, this time decreases.
What is taking so long? Have I missed anything?
Happy for answers.
Solved! Go to Solution.
Hello,
that very much might depend on the run control device (P&E? Segger? OSJTAG?) you are using, plus the memory range you are preserving.
And it depends on the 'preserving algorithm' too. What I have seen is that usually reads the preserved memory range from the target (takes some time), erases the full device (takes some time too), then merges the preserved memory read previously with the application you download (takes little time again), and then programs the full thing to the to the device (that definitely takes some time). So if you are using a slow OSJTAG, it might be worth trying a faster JTAG debugging device (P&E Multilink or Segger) to speed things up.
Hope this helps,
Erich
Hello,
that very much might depend on the run control device (P&E? Segger? OSJTAG?) you are using, plus the memory range you are preserving.
And it depends on the 'preserving algorithm' too. What I have seen is that usually reads the preserved memory range from the target (takes some time), erases the full device (takes some time too), then merges the preserved memory read previously with the application you download (takes little time again), and then programs the full thing to the to the device (that definitely takes some time). So if you are using a slow OSJTAG, it might be worth trying a faster JTAG debugging device (P&E Multilink or Segger) to speed things up.
Hope this helps,
Erich
Hi and thank you for quick answer.
I am using OSJTAG and yes, it is indeed slow. And you reply explains why it takes soooo long... I will try using my Lauterbach JTAG instead =), allthough it lacks the nice IDE integration to CodeWarrior (Eclipse).
Thank you.