Very slow flash programming when preserving memory area

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Very slow flash programming when preserving memory area

跳至解决方案
1,139 次查看
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.

标签 (1)
0 项奖励
回复
1 解答
841 次查看
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 项奖励
回复
2 回复数
842 次查看
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 项奖励
回复
841 次查看
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 项奖励
回复