No response after GET_CMD command for STM32

[Mihaita Ivascu]

Posted on July 12, 2018 at 08:11

Hello,

    I have the following situation: UARt communication between ARM A9 uP on Xilinx Zynq 700 series as a master and STM32 uC as a slave. I have followed the steps for issuing GET_CMD command(needed in a firmware update process) from USART protocol implementation  for STM32:

https://www.st.com/content/ccc/resource/technical/document/application_note/51/5f/03/1e/bd/9b/45/be/CD00264342.pdf/files/CD00264342.pdf/jcr:content/translations/en.CD00264342.pdf

 

   After writing GET_CMD(0x00 + 0xFF) was succesfully, nothing can be read from UART. No response, no ACK or NACK received from STM32 side.

   Previous UART ACK ere received but the ACK or NACK for GET_CMD command was not received. 

   The same code and same implementation have worked when the master was an imx6ul platform. But if I try to send the command from Zynq 7000, the STM32 will not give any response for GET_CMD and so the master will wait endlessly.

   What could be the issue or what should I investigate on STM32 side?

Thanks,

      Mihaita

#stm32-usart

[AvaTar]

Posted on July 12, 2018 at 10:53

I would start with scoping the communication both with the Zynq and the imx6 platform, and compare for differences.

[Tesla DeLorean]

Posted on July 12, 2018 at 11:24

Make sure to be using even parity. ie 8E1

[Mihaita Ivascu]

Posted on July 12, 2018 at 12:07

I think that if parity would have been an issue I would not have received ACK from previous commands.

But as soon as I send GET_CMD command there is neither ACK vor NACK from the STM32.

[Tesla DeLorean]

Posted on July 12, 2018 at 14:26

Probably..

I would suggest you stick another micro to monitor the RX and TX pins, or use a logic analyzer, to see if any of those can see an anomaly in the data flow or sequencing.

The System Loader is relatively simple, and has a watchdog timeout. Perhaps monitor the state of NRST

[Mihaita Ivascu]

Posted on July 16, 2018 at 12:38

I think is a parity issue after all. But on ARM A9 side, not STM

I have set parity even 1 stop bit and 9bit data(because of the parity bit from what I read about STM32).

When I am sending 1 byte command(0x7F) I receive 0x79 as expected and the output on picoscope 6 looks right as in the first attachment(1byte_cmd).

When I send 2 bytes cmd(0x00 + 0xFF) I see on TX line on picoscope that is only first byte sent but with no stop bit(high) instead another start bit(?) at the end. And obviously there is no response on RX from STM Please see 2byte_cmd attachment.

Thanks,

Mihaita

________________ Attachments : 2byte_cmd.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxPo&d=%2Fa%2F0X0000000axk%2FC6wRrRdhqg7hAH4_XnTCzhxocWYURgz91c5q6LhOvZc&asPdf=false1byte_cmd.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxPj&d=%2Fa%2F0X0000000axf%2F3sXJoU_5KKDGXIsDY54QSjb7JFXKn5vhp2KgyS.9hhg&asPdf=false