2 Replies Latest reply on Apr 27, 2015 4:03 AM by JeDe_2143696

    puart rts/cts and eeprom working together



      with our own design board based on 20737 QFN we want to use puart with rts/cts so we need P0, P1, P2 and P3. We also want to use an eeprom like in the smart tag bcm920737tag-03 that we use for tests.

      But as mentionned in other discussion, in the smart tag P1 is taken by the WP of the eeprom, so we would like to use in our design the P4 for the WP (or another free gpio).

      Will this be working with some modifications in the include files and what are the modifications we need to do ?

      thanks for help


        • 1. Re: puart rts/cts and eeprom working together

          According to the WICED™ Smart Hardware Interfaces (note that this was written for the SoC, but can also be used for the SIP module with limitations such as the WP pin that is bonded internally to P1), you should be able to use P2 (RXD), P0 (TXD), P3 (CTS) and P1 (RTS).


          I think these would first need to be configured by the high level API (example configuration for the low level API is available in the document referenced above) from within the application.


          Note that Hardware flow control is optional (and has never been tested on the TAG board, which uses the SoC), in which case, CTS and RTS signals will not be configured by the driver API.


          There is more information on GPIO configuration/pin mappings here near the bottom: BCM2073XS GPIO Basics


          Also note that with an SoC design, you and the regulatory house you choose to work with will be responsible to take the device through full regulatory with little support through the forum as we are only setup internally to support the leveraging of our Limited Modular Approval for the SIP.

          • 2. Re: puart rts/cts and eeprom working together

            Update :

            Hello mwf_mmfae, thanks for your answer

            I just realize that I was going to a bad direction: we don't need the rts/cts anymore and so we don't need to make a SoC design

            I thought I needed the hardware flow control because I could not achieve a puart speed greater than 19200 without problem of fifo overrun

            This was because in my interrupt function I sent some debug info with ble_trace function which took too much time, by removing these traces, I can communicate at 115200 and it uses only 1/3 of the 16 bytes fifo capacity !!!

            best regards