KL03 ROM bootloader inconsistent behavior

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

KL03 ROM bootloader inconsistent behavior

ソリューションへジャンプ
2,244件の閲覧回数
laszlomonda
Contributor V

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 件の賞賛
返信
1 解決策
1,706件の閲覧回数
laszlomonda
Contributor V

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!

元の投稿で解決策を見る

1 返信
1,707件の閲覧回数
laszlomonda
Contributor V

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!