Problem bypassing ROM bootloader using USBDM on KL27Z256

[uribendelac]

Hi pgo,

Hopefully you can help me figure out my problem:

I use a proprietary board based on a KL27Z256VFM4. I have a simple test application that implements CDC profile (using mbed libraries) and sends some data over USB.

If I use USBDM to flash the application and run it directly (hence not going through onboard ROM booloader), the virtual serial port will be detected properly by Windows and the data will be received correctly. If, instead, I try to run the application from power up, i.e. after the bootloader starts and then switches to my application, Windows will detect the connection on the USB bus but fails enumerating (it seems the microcontroller doesn't send any enumeration data at all). The same happens if I use USBDM to connect to the pre-programmed target, without reprogramming it, and run from debugger.

According to the KL27Z256 reference manual, the bootloader makes some changes to the chip, which it fails to revert before running the user application (like enabling power and clock to the ports), but those changes do not seem as if they should be a problem preventing my application from enumerating correctly.

In any case, since the booloader somehow seems to interfere with my code, I am now trying to bypass the bootloader. In my application (in startup_MKL43Z4.S) I change the flash configuration words to 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFF3FFE, and I confirmed that those changes take place in the resulting hex file. The last word should set up FOPT and FSEC bytes such that the controller boots from flash instead of ROM. Yet, when burning this image with USBDM, the booloader will still start, and the peripheral view shows that the FOPT byte has 0xFF instead of the required 0x3F. BTW, if I try to burn the image with OpenOCD instead of USBDM, KDS will tell me that it converted my requested 0x3F into 0xFF for some reason.

Any idea what is going on? Do you also convert the FOPT value from 0x3F into 0xFF, and if so, why?

Thanks,

Uri

[pgo · Accepted solution]

Hi Uri,

With the standalone programmer the Image security option should result in the target being programmed without any modification to the security area in the image file loaded.  It will however refuse to program the target to a permanently secured configuration.

The other options may modify the configuration area.

When using the debugger there are similar options but they are more restricted.

bye

[uribendelac]

Hi pgo,

I haven't been able to program the image with correct security fields from within USBDM, no matter what I tried, but I have managed to program the image with correct security bytes from the stand alone programmer as you suggested, and then connect with the debugger with reset without programming, so I can debug again.

Thanks!

Uri