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?