0x0 ~0x7FF (1st FLASH sector) is always erased, debugging with USBDM

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

0x0 ~0x7FF (1st FLASH sector) is always erased, debugging with USBDM

Jump to solution
1,021 Views
madisonchou
Contributor III

Hi,

I am porting CW10 project to KDS and encounter difficulties when debugging with latest USBDM (V4.12.1.30). Our target is MK10DX128M7.

I have project reside on FlexNVM with interrupt vectors in 0x0~0x400 just like any normal project.   Then, I have another project that is in FLASH, but arranged to avoid using 0x0 ~ 0x7ff (1st FLASH sector) by the linker file:

  m_interrupts          (RX)  : ORIGIN = 0x00001000, LENGTH = 0x00000400

  m_flash_config        (RX)  : ORIGIN = 0x00001400, LENGTH = 0x00000010

  m_text                (RX)  : ORIGIN = 0x00001410, LENGTH = 0x0001EBF0

This arrangement works in CW V10 using USBDM.   But doesn't work in KDS using USBDM.   After code is downloaded, it is obvious that problem is due to 0x0 ~ 0x7FF being erased, even I have selected "Selective Erase (by sector)".

Is there a work-around?   Thanks!

Jei

0 Kudos
1 Solution
726 Views
pgo
Senior Contributor V

Hi Jei,

Using the working copy of USBDM which is slightly later than the release version I was able to do what I believe you were trying but there are several caveats.

  • If you are not programming the security area at 0x400 then is necessary that its present contents unsecure the chip - by default the USBDM interface will program and hence erase that area even if the image does not contain data.  You have to disable this. (see below)/
  • I found it necessary to modify the standard start-up code to set the stack pointer as this will no longer be loaded from the reset vector correctly on reset.

The setup I used for the debugger is as follows:

  • Change to selective erase.
  • Change to using security field from image (there should NOT be one).
  • Don't reset the target
  • Do set the initial PC to whatever the reset handler is called.

pastedImage_5.png

pastedImage_6.png

You may have to change the above Reset_Handler depending on your code.

The example changes to the KDS startup code should be similar to:

pastedImage_7.png

I tested this on a MK20DX128M5 as follows:

  • Programmed the entire flash image with random data (except for the security area which has FFFFFFFFFEFF etc to unsecure)
  • Ran a program with the rom relocated to 0x1000.
  • The debugger appear to work correctly.
  • I used the memory window to check the rom contents.  They appear unchanged except for the region starting at 0x1000.
  • I used the USBDM memory dump program and examined the memory image.  It appeared as expected.

I believe the above should work with the current release version with the modified device file provided earlier.  If not it would be best to wait a few days for Version 4.11.1.50 to be released.

bye

View solution in original post

0 Kudos
4 Replies
725 Views
pgo
Senior Contributor V

Hi Jei,

The sector size is set incorrectly in the device file (arm_devices.xml).

Please try the attached file.

bye

0 Kudos
725 Views
madisonchou
Contributor III

Hi pgo,

The new device data file doesn't seem to make any difference.   After code download, 0x0 ~0x7FF remains erased.

One more piece of info.  The "ARM Programmer" is now good.  Though, I am not 100% sure because I wasn't as careful as today.  I did this yesterday and today:

Set linker to generate S-record output.   Use "ARM Programmer" to program the my target.  First, mass-erase the target.   Select EraseSelective.   Then, open a S-record of 1st project that uses the 0x0 region.  Programming is successful.   Open S-record of 2nd project that doesn't use 0x0 region.   Programming is successful.   Use "USBDM Memory Dump" and verified the bits in 0x0~0x7FF are intact, today.   (But I believe it was erased when I did the same yesterday.)

Jei

0 Kudos
727 Views
pgo
Senior Contributor V

Hi Jei,

Using the working copy of USBDM which is slightly later than the release version I was able to do what I believe you were trying but there are several caveats.

  • If you are not programming the security area at 0x400 then is necessary that its present contents unsecure the chip - by default the USBDM interface will program and hence erase that area even if the image does not contain data.  You have to disable this. (see below)/
  • I found it necessary to modify the standard start-up code to set the stack pointer as this will no longer be loaded from the reset vector correctly on reset.

The setup I used for the debugger is as follows:

  • Change to selective erase.
  • Change to using security field from image (there should NOT be one).
  • Don't reset the target
  • Do set the initial PC to whatever the reset handler is called.

pastedImage_5.png

pastedImage_6.png

You may have to change the above Reset_Handler depending on your code.

The example changes to the KDS startup code should be similar to:

pastedImage_7.png

I tested this on a MK20DX128M5 as follows:

  • Programmed the entire flash image with random data (except for the security area which has FFFFFFFFFEFF etc to unsecure)
  • Ran a program with the rom relocated to 0x1000.
  • The debugger appear to work correctly.
  • I used the memory window to check the rom contents.  They appear unchanged except for the region starting at 0x1000.
  • I used the USBDM memory dump program and examined the memory image.  It appeared as expected.

I believe the above should work with the current release version with the modified device file provided earlier.  If not it would be best to wait a few days for Version 4.11.1.50 to be released.

bye

0 Kudos
725 Views
madisonchou
Contributor III

Hi pgo,

Thanks for you time.   Security Option is the trick!!

But my project runs to never land in the debugger.  So something is still wrong.   Though, that will be a different thread after I characterize it.

Thanks again!!!

Jei

0 Kudos