Very slow flash programming when preserving memory area

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Very slow flash programming when preserving memory area

Jump to solution
1,258 Views
deekay
Contributor I

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.

Labels (1)
0 Kudos
Reply
1 Solution
960 Views
BlackNight
NXP Employee
NXP Employee

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

View solution in original post

0 Kudos
Reply
2 Replies
961 Views
BlackNight
NXP Employee
NXP Employee

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

0 Kudos
Reply
960 Views
deekay
Contributor I

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.

0 Kudos
Reply