Blhost.exe Reading back data written to flash

[admin6]

Is there a way that blhost.exe (v2.0.0) can read back new data written to flash without having to reset the target first?

See attached log.

What actually happens is that old data is read back until the target is reset.

The target is a MKL27z64vLh4 in a FRDM-KL27z eval board.

As the attached log shows it is attached via USB HID (J10).

The target is reset with the SW1 button held down in order to start the ROM bootloader rather than the demo flash application.

[Sebastian_Del_Rio]

Hi Rob, I hope you're doing well!

Do you see this same behavior if you use UART instead of USB to connect to the bootloader with the blhost?

Best regards,

Sebastian

[admin6]

Hi Sebastian,

Thank you for taking the trouble to help. Yes I am OK for now thank you, I hope you are well too.

That is an interesting question, the answer would reveal if it was a USB buffering problem, or not.

Sadly, right now, due to working from home during the lockdown, I am unable to test blhost.exe diectly with a UART  (unless there is a way of making the OpenSDA see a UART I/O and forward its data over USB to a virtual com port. Not something I would normally do because using the excellent blhost.exe directly on the KL27z USB port provides independence from additional hardware in the field. )

Best wishes,

Rob

[Sebastian_Del_Rio]

Hi Rob, 

The UART peripheral can be used through the OpenSDA interface included in the FRDM-KL27 by using the -p argument, with the desired speed and COM port as arguments. This can be seen explained in Chapter 4 of the blhost User's Guide.

As an additional note, a new release of the blhost utility is available to download from the MCUBOOT page of our website. Could you please try with this new version?

Please let me know of your results.

Take care, best regards,

Sebastian

[admin6]

Hi Sebastián,

    Thank you for your helpful reply.

    To answer your question; 

     -  yes I do still see the same behaviour with the UART (LPUART0 thru SDA to COM5 on Windows 10).

    To provide more detail;

     -  it is only necessary to read a block of 512 bytes before reading the written addresses to verify the content.

     -  it still happens with v2.6.2 blhost on both the USB and UART ports, it is not a timing issue.

     -  the write is working perfectly, but it might be a bit confusing not verifying the write until after a block read.

    Please find logs of 2 sessions with blhost.exe v2.6.2  (to KL27x64VLH4 on a FRDM-KL27z).

    -  one using the UART

    -  other using the USB

  Many thanks, blhost is very useful and robust!

  Rob

[admin6]

Same problem with more recent blhost.exe version 2.4.1 (December 2019 vintage).

[admin6]

Hmm,

After changing the content of flash it is apparently necessary to read a large number of bytes (2048), then re-read the number of bytes required.

Therefore it seems this might be a buffer flushing issue, possibly in the USB interface.