- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello!
I am using a FRDM-MCXN947 development board, and the most recent (as of writing this) MCX Nx4x Reference Manual here: https://www.nxp.com/doc/MCXNx4xRM.
I'm trying to use the Bootloader commands, over I2C ISP, to flash an image onto the board. I'm running into some issues - I can't read a GetStatusReponse (section 14.4.7), sometimes GenericResponse (section 14.4.7), and sometimes framing Ack (section section 14.4.4), after my write.
I'm using the default bootloader I2C pins (SDA = J7[3], SCL = J7[7], section 12.2.1) and slave address (0x10, section 14.8.1). The source clock I provide for the pins is 400kHz through FlexCOMM, although I'm not 100% sure that's what the communication speed actually ends up being, or if Bootloader uses my pinmux settings? I thought the Bootloader was supposed to adjust automatically, up to 400kHz (section 14.8.1) anyways. My digital logic analyzer suggests the actual clock rate is somewhere around 550kHz. Here's some screenshots if it helps.
These are the steps I follow:
0. Refresh state.
Flash a blinky or something onto the board. I use LinkServer, but anything probably works. The point is to put the bootloader into a fresh state when you enter it.
1. Enter ISP bootloader mode.
Press the ISP button, RESET button, release RESET button, release ISP button.
2. Send a Ping (Section 14.4.2) to confirm connection.
I write a ping, 5A A6. I read a ping response, 5a a7 00 03 01 50 00 00 fb 40. Great!
3. Send GetProperty (section 14.5.2) to get the flash start address.
I write GetProperty, 5a a4 08 00 94 f7 07 00 00 01 00 00 03 00. I read a framing Ack , 5a a1. When I try to read more, SCL goes low, SDA goes high. I timeout after waiting 5 seconds, then SDA goes low again after some fuss, probably from the I2C master I'm using.
I've noticed for the command FlashEraseAll, a GenericResponse is returned fine after a half a second or so delay waiting for the framing Ack. Same for Reset, but without as much delay.
For WriteMemory, I get an ACK and no GenericResponse. For Data packets, not even an ACK could be read, unless I called WriteMemory immediately before it.
But, I'm hoping if I can just figure out why GetProperty Acks but sends no GetPropertyResponse, I can figure out the others too!
Thank you for your time!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
An update:
When you have a framing header on a command packet, the parameters, although 32-bits in length, are on a 10-byte boundary, so they're not 32-bit aligned. I forgot to account for that before.
Here's an updated GetProperty (current version, internal flash).
5a a4 0x 00 4b 33 07 00 00 02 | 01 00 00 00 | 00 00 00 00
This GetProperty does receive a response.
Ack
5A A1
GetPropertyResponse (status code = 00 00 00 00, current version = 00 02 03 4b)
5a a4 0c 00 05 72 a7 00 00 02 00 00 00 00 00 02 03 4b
If that fixes my other issues I'll update.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Marek,
I'm accessing the Bootloader from a different board running FreeRTOS, not my computer, so I won't be able to use blhost in my situation.
But, in the meantime, I can look at blhost's source code to see how it handles the bootloader commands over I2C, and make sure the steps here work: https://docs.nxp.com/bundle/AN14460/page/topics/flash_programming_with_blhost.html.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
An update:
When you have a framing header on a command packet, the parameters, although 32-bits in length, are on a 10-byte boundary, so they're not 32-bit aligned. I forgot to account for that before.
Here's an updated GetProperty (current version, internal flash).
5a a4 0x 00 4b 33 07 00 00 02 | 01 00 00 00 | 00 00 00 00
This GetProperty does receive a response.
Ack
5A A1
GetPropertyResponse (status code = 00 00 00 00, current version = 00 02 03 4b)
5a a4 0c 00 05 72 a7 00 00 02 00 00 00 00 00 02 03 4b
If that fixes my other issues I'll update.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Although the reference manual says the Memory ID field is optional (14.5.7), only once I added it I got a GenericResponse.
Only after that, my Data packets would ACK. Seems to work now!


- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jasmine,
there is implementation of the protocol in python available as open source, see https://github.com/nxp-mcuxpresso/spsdk
The application for the communication with bootloader is named "blhost"
Marek
