Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
5 years, 8 months ago.
Programming bare bones MK64 with mbed binary ...
Hi all,
Has anyone out there managed to program their own custom PCB (with K64 processor) using an mbed .bin file created for a FRDMK64F? We are having no end of issues with this ...
I have a custom board with a bare NXP MK64 processor on it. To test it, I took blinky code from Keil, compiled it as a .hex, and loaded it using JTAG. Which worked a treat on the PCB.
I then tried an Adafruit CMSIS-DAP JTAG/SWD debug adapter kit. This was pretty old and although I could flash the MK64 with .hex files using it, it didn't work with the mbed binary. I think this is due to needing some sort of flash algorithm specifically for the MK64 which, since the board is old and no longer supported, I couldn't find. Oh well ...
What I then tried was using the bootloader on a FRDMK64F board to try to program the bare processor using the SWD connections in the FRDMK64F schematic. I've seen people do this for other FRDM boards in the forums. I broke the track as other people have done to isolate the MCU from the MK20 bootloader, did that on two boards, then managed to get the bootloader on one board to program the MCU on another. Which worked for both mbed .bin and .hex files. But making the same connections to the bare bones processor failed to program it. The only explanation I have is that some supporting lines (power, reset, or the UART?) which are connected on the FRDM boards (even after isolation of the SWD clock) aren't on my board so I'm checking that.
A friend gave me the loan of a Segger flasher, which seemingly supports the MK64 family of processors and binary files. After some issues with security bits and having to wipe the processor, I could happily transfer .hex files. But, try as I might, it won't flash with the mbed binary. I'm experimenting with the offset (seems to be either 0x0 or 0x5000 on most processors) but still can't get the darned thing to wake up. At this point I'm trying now to convert the .bin to a .hex file using bin2hex or hexplorer, but so far, no luck. And sending off a PCB with a copy of the MK20 bootloader from the FRDMK64F schematics as another solution.
Can anyone out there offer some tips? This shouldn't be this complicated ...
1 Answer
5 years, 8 months ago.
Hi James,
A .hex file will have some header on it so that the flash algorithm can check and flash it. However, for a binary file, the flash algorithm will look for a correct vector table. If it does not detect a correct vector table, it will throw an error. So can you double check that your binary file has the correct vector table and make sure that you have the latest flash algorithm for the K64F? You can check and find the latest flash driver here: https://armmbed.github.io/DAPLink/
Please let me know if you have any questions!
- Peter, team Mbed
If this solved your question, please make sure to click the "Thanks" link below!
Thanks Peter. It might be an issue with the Segger flasher which, for speed, doesn't always completely erase the MCU. I'll keep trying ...
posted by 17 Aug 2018I've continued doing a few more tests to see what's going on ...
On the FRDMK64F board, we're using two 'firmware' files. These are
0244_k20dx_bootloader_update_0x5000.bin 0247_k20dx_frdmk64f_0x5000.bin
I can connect two FRDM boards and use the bootloader on one to program the MCU on the other with an mbed binary once those firmware files have been uploaded.
What I then did was connect the MK20 bootloader on one of the FRDM boards to a bare K64 chip using the SWD clock, reset, and data pins. I then went through the process of loading the 0244 file and then the 0247 file. It was at this second file load that the bootloader on the FRDM board shows a red led.
Looking at the bootloader 'drive' when it fails, I get the following error
Error: An error occurred during the transfer Type: Transient
When I looked at the reset line after trying to transfer the 0247 file, I find it oscillates between high and low. On the FRDM to FRDM transfer, it is held low and then returns high. On the FRDM to bare MK64 it doesn't return high but spikes between high and low.
I checked whether this 'cycling' of the reset pin is at bootloader or MCU side, and it is on the MCU side.
So my problem seems to be a reset issue. I've tried a pull-up resistor (didn't work) so anyone else seen this? A separate reset button needed on the MCU side?
posted by 29 Aug 2018