KL03 ROM bootloader inconsistent behavior

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

KL03 ROM bootloader inconsistent behavior

Jump to solution
1,923 Views
laszlomonda
Contributor IV

Hi there,

I'm running the ROM bootloader of the MKL03Z32VFK4 and noticed something very weird. The first time I run the "blhost --usb --buspal i2c -d flash-erase-all-unsecure" command, it fails, but the second time it succeeds.

1st blhost invocation:

$ blhost --usb --buspal i2c -d flash-erase-all-unsecure
Inject pre-config command 'i2c'
[01 00 0c 00 c1 00 00 02 10 00 00 00 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
<03 00 0c 00 a0 00 00 02 00 00 00 00 c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>
Successful generic response to command 'i2c'
- took 0.000 seconds
Response status = 0 (0x0) Success.
Inject command 'flash-erase-all-unsecure'
[01 00 04 00 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
<03 00 00 00 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>
usbhid: received data phase abort
<>
sendCommandGetResponse.readPacket error 5.
processResponse: null packet
- took 0.000 seconds
Response status = 10004 (0x2714) No response packet from target device.

2nd blhost invocation:

$ blhost --usb --buspal i2c -d flash-erase-all-unsecure
Inject pre-config command 'i2c'
[01 00 0c 00 c1 00 00 02 10 00 00 00 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
<03 00 0c 00 a0 00 00 02 00 00 00 00 c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>
Successful generic response to command 'i2c'
- took 0.000 seconds
Response status = 0 (0x0) Success.
Inject command 'flash-erase-all-unsecure'
[01 00 04 00 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
<03 00 0c 00 a0 00 00 02 00 00 00 00 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>
Successful generic response to command 'flash-erase-all-unsecure'
- took 0.000 seconds
Response status = 0 (0x0) Success.

I've put the I2C protocol dump of the first and second blhost invocations side by side. Please note that the first invocation is directly followed by the second invocation. There is no extra communication in between.

blhost-dump.png

According to the above, the KL03 ROM bootloader fails to answer the first invocation but works perfectly for the second invocation. Upon subsequent calls, this pattern continues:

  1. KL03 ROM bootloader starts up
  2. blhost --usb --buspal i2c -d flash-erase-all-unsecure -> FAIL
  3. blhost --usb --buspal i2c -d flash-erase-all-unsecure -> SUCCESS
  4. blhost --usb --buspal i2c -d flash-erase-all-unsecure -> FAIL
  5. blhost --usb --buspal i2c -d flash-erase-all-unsecure -> SUCCESS
  6. blhost --usb --buspal i2c -d flash-erase-all-unsecure -> FAIL
  7. blhost --usb --buspal i2c -d flash-erase-all-unsecure -> SUCCESS
  8. ...

Lastly, I must also note that I had to add 2 lines of code to BusPal to go this far. Without the extra read that I added, it always fails because it considers the extra 0 byte that the bootloader sends part of the framing packet. According to the protocol documentation, "0x00 will be sent as the response to host if the target is busy with processing or
preparing data", so it seems to be legit, but it's a bit strange that it's always sent, even when the communication speed is set to 1kHz in which case the bootloader should have plenty of time to do processing.

Please somebody explain the above to me. I need the bootloader to behave consistently, and I cannot give any meaningful explanation other than the KL03 ROM bootloader is buggy.

Thanks!

- Laci

0 Kudos
1 Solution
1,385 Views
laszlomonda
Contributor IV

Mr. Santiago J. González Fabián has just let me know about errata ID 8060 which is the likely culprit here. Looks like I will have to explicitly retry to work around this bug. Thanks a ton, Santiago!

View solution in original post

1 Reply
1,386 Views
laszlomonda
Contributor IV

Mr. Santiago J. González Fabián has just let me know about errata ID 8060 which is the likely culprit here. Looks like I will have to explicitly retry to work around this bug. Thanks a ton, Santiago!