Hello @95504669 ,
Posting here the best practice shared in the github related issue by Gianni Trevisiol: https://github.com/Azure/azure-sphere-samples/issues/222
As a best practice, it's recommended that UART flow control configurations do not differ on the two communication parties.
That said, the likely reason for which case 2) works is that when the Azure Sphere's CTS pin is connected to the NFR's RTS, its current state (undefined btw) "happens" to trigger the hardware flow control circuit between the two.
To prove this, you can use case 1), and simply try to separately pull-up(3.3V)/down(GND) the NRF's RTS only: the FW update should similarly succeed/fail respectively.Therefore, you can either:
1) Enable flow control on Azure Sphere (on the NRF52 it's already enabled in its bootloader) and cross-connect CTS/RTS between the two (like shown in the sample).
2) Disable flow control on Azure Sphere and pull-up RTS (and CTS optionally, since already done by the bootloader) on the NRF... but accept potential communication issues.
Remember:
- Please accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer. Here is how.
- Want a reminder to come back and check responses? Here is how to subscribe to a notification.