9 Replies Latest reply on Nov 30, 2015 6:38 PM by temic_1089541

    ROM code driving SPI CS before initialization

      We are testing out the SPI2 slave communications of the BCM20736E with the following pin configuration:

      SPI_2_CS: P32

      SPI_2_CLK: P24

      SPI_2_MISO: P25

      SPI_2_MOSI: P27


      Prior to our code being loaded and executed, the ROM code is driving the output of the chip select line.

      We monitored the chip select line, and there is UART ascii data being put out on that pin prior to our reconfiguration for SPI.

      See Terminal_Broadcom.jpg


      Because it takes the Broadcom module three seconds to load, the master device is already up and running by the time the module is configured.

      This is causing a collision when the master device attempts to communicate to the slave when it's driving the port with UART data.

      Both devices end up driving the line at the same time.


      How do I stop the Broadcom UART debug output on that GPIO port?

        • 1. Re: ROM code driving SPI CS before initialization

          I don't know if this will help or not, but something I tried to use for a similar issue:

          I am using the Heart Rate Monitor profile (blehrm.c) - so you might look at whatever profile you are using to see if there is something comparable.

          Not sure what the right numbers would be for your system.. I

          'm guessing 32 for teh Xmit ?? for the Rcvr.


          PLACE_IN_DROM const BLE_PROFILE_PUART_CFG blehrm_puart_cfg =


              /*.baudrate   =*/ 115200,

              /*.txpin      =*/ PUARTDISABLE | 32,       // GPIO pin number

              /*.rxpin      =*/ PUARTDISABLE | ??,       // GPIO pin number


          • 2. Re: ROM code driving SPI CS before initialization

            I don't think this will work because the port is being driven with the UART output before my code is even executed.


            When you say "PLACE_IN_DROM", can you expand on this comment a little more.

            How do you put code in the ROM?

            • 3. Re: ROM code driving SPI CS before initialization

              Seriously... I don't understand having tech support on a forum if nobody from Broadcom will even read and reply to my question!

              • 4. Re: ROM code driving SPI CS before initialization

                The long holiday has the team in catch-up mode.


                I will ask someone from the apps team to respond as soon as they have a chance.


                userc_19497 JacobT_81 jota_1939431

                • 5. Re: ROM code driving SPI CS before initialization

                  Hi temic_1089541,


                  I apologize for the delay in replying. Is this a custom app you're using? If it is, can you attempt to emulate the problem with one of the default apps provided in the SDK?


                  I believe that this is a problem with your debug trace configuration. It seems to be routed to the PUART which generally is pre-configured on P32. With that said, can you copy and paste any relevant code relating to the PUART?


                  A couple things to try immediately, would be configuring the PUART to pins 24/25 or disabling them. Secondly, attempt to disable any form of traces. There are multiple means of doing so discussed in the following posting: How to disable 20737S SDK trace, BLE_TRACE_DISABLE?.


                  It's also possible that this is happening only as a result of configuring the CS line, inadvertently routing traces to the pin. To test this, just swap the CS pin number on the configuration. If this is the only thing that fixes it, we'll need to delve further into the pin mux and discuss the problem with the developers. 


                  Again, sorry for the delay.



                  • 6. Re: ROM code driving SPI CS before initialization

                    Disabling the tracing as discussed had no effect. Scope shot below shows power to device (yellow trace), P32 output (green trace), and another GPIO we drove high as the first operation the code performed. The UART debug output is @ 3.13S. Our code is not executed until after that.



                    Moving the SPI to another output pin configuration does me no good, as the board assemblies have already been fabricated.

                    • 7. Re: ROM code driving SPI CS before initialization


                      PLACE IN DROM is not a comment.  I think it is some kind of Broadcom Macro that is resolved at compile or link time.  I'm not a Broadcom Support engineer, just another user like you.  Sorry I don't have any more details.


                      The other thing that comes to mind, which you have probably already checked is whether or not your CS pin is bonded with another pin.  When the module has two pins bonded together, the one you are not using must be disabled.  The Datasheet will tell you which pins are affected.




                      p.s. I found this on page 17 of the Wiced Smart Application Note:

                      I'm guessing that if you took a look at the Hello Sensor Application to see where and how this variable is used it might shed some light.


                      • 8. Re: ROM code driving SPI CS before initialization

                        Can you confirm that this happens even with Hello Sensor as well? Or is it only when you are using your custom app? If you can confirm that a sample app like Hello Sensor is problem-free we can approach this from a firmware standpoint.


                        And if the problem only exist with your sample app, we then need to know whether or not it is related to the initialization of the SPI hardware by having you comment it out and rerunning your code.

                        Also, what evidence do you have that this happens prior to code execution? Is this because you're running traces or toggling a GPIO? Please keep in mind that there is a lot of code execution prior to the application thread ever being reached.



                        • 9. Re: ROM code driving SPI CS before initialization

                          JacobT_81 and userc_7511

                          Found the issue inside our APPLICATION_INIT() function:

                          We had replaced the Peripheral UART config in bleapp_set_cfg() with a NULL instead of disabling because it wasn't being used.

                          1 of 1 people found this helpful