Visitor

Question

Extended Erasure command on STM32F446ZE

3 replies
21 views

Hi,

I’ve written a long question with a lot of detail about an observed behavior on using the builtin bootloader. It wasn’t accepted because it missed a tag. I clicked on the right side tags thinking this selects a tag. It does not. It shows all content for that tag. and not only that, it also completely erases my post, the back-button does not work. This is really bad behavior from this forum software, please fix it.

And now you’re getting the faster, not-so elaborate question:

I see the following communication when updating a firmware using the cube programmer (left programmer, right MCU answer):

EE..........080000000800FF..44BB ..79..797900..............79.... 000500000001000200030004000504.. ................................ ................................ ................................ ................................ ................................ ................................ ..........7979797979797979797979 ................................ 79797979797979797979797979797979 31CE0800000008FF00000220E1310008 ................................ E12E0008E92E0008F12E0008F92E0008 ................................

Please note that the 44BB command does not produce the expected 2 bytes of ACK (79), but instead about ~13 more. The last one is likely to be part of the 31CE write memore due to some concurrency issues in obtaining and displaying these through my setup.

Please advise as to why so many more ACK bytes are received. AN3155 in revision 22 was consumed for this analysis.

Diez

F

FBL

ST Technical Moderator

Hi @Diez Roggisch

I’m sorry you lost your draft while trying to add a tag, especially after taking the time to write a detailed question. I understand how frustrating that must have been.

I’ve shared your feedback with @Maxime MARCHETTO , so they can review the tagging workflow and the loss of unsaved drafts. Thank you for bringing this to our attention.
You can report similar issues in feedback forum.

Now coming to your questions, in my understanding, AN3155 describes one ACK after the 44 BB command and one response after the erase payload; it does not describe ACKs for each erase unit. The payload appears formed for six erase units, with checksum 04.

Now we are not sure the repeated 79 bytes are coming from MCU or capture path. Can you capture a simple erase exchange, with MCU TX and RX recorded separately and timestamps included?

To give better visibility on the answered topics, please click on "Best answer" on the reply which solved your issue or answered your question.Best regards,FBL

D

Diez RoggischAuthor

Visitor

Hi FBL, thanks for the speedy reply.

The capture as provided is probably not going to improve. To explain the setup (that was lost in my first draft)

- NUCLEO board, ST Link UART mapped to one of the eligible UART3 pin pairs.

- Two FTDI adapters connected to UART3 TX and RX with their RX pins.

- A little Rust application spawning two threads to read the two data streams, pushing them into a queue.

- The visualisation as you see it just collects the bytes and assigns them to their relative side, each incoming byte progresses the output on the other side by one “.”

So the jitter that can be observed in the above snippet is due to Windows and the two com ports and threads introducing it. I can’t improve this right here, I will try and use a logic analyzer - but that’s next week.

I ran the same erasure sequency by using cube programmer with `-e 0 1 2 3 4 5`, this is the result:

................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ......7F........................ ................................ ............7F02FD00FF11EE...... ..........................1F7901 ................................ 042179790B3100010211213144637382 ........080000000800FF.......... 927979................7979007901 ..........................02FD02 04217979010421797901042179...... FD02FD02FD11EE..............0800 ..............790104217979...... 00000800FF11EE.................. ..............797900797979FF7F00 ..1FFFC0082803FC11EE..0800000008 80..................79.......... 00FF11EE1FFFC00828.............. ..................797900797979FF ......03FC11EE..080000000800FF44 7F0080........79................ BB000500000001000200030004000504 ................................ ................................ 79790079........................ ................................ ................................ ................................ ....................79.......... ................................ ................................ ................................ ................................ ................................ ................................

This looks different as in the amount of ACKs is significantly fewer. I assume the sequence 797900 is the two ACK plus result from the 11EE command, putting the number of ACK for the erasure to the expected two.

I think I really have to tweak the setup to get a fully synchronous capture using the LA. Then we can be sure about the ACK-allocation to commands. I’ll be back with these results on Monday.

Thanks for the support,

Diez

Maxime MARCHETTO

ST Community Manager

Hello @Diez Roggisch,

Welcome to the ST Community, and thank you for your feedback.

To make the experience clearer, I’ve removed the “Popular tags” widget from the question creation page.

If you have more suggestions, please share them in the Feedback forum. Your feedback is welcome.

Best regards,
Maxime

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question.

Sign up

Click below to sign in

Login to the community

Click below to sign in