ROM code driving SPI CS before initialization

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

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?

0 Likes
1 Solution
Anonymous
Not applicable

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

};

View solution in original post

0 Likes
9 Replies
Anonymous
Not applicable

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

};

0 Likes
Anonymous
Not applicable

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?

0 Likes
Anonymous
Not applicable

Hi,

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.

Eric

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.


Puart.PNG



0 Likes
Anonymous
Not applicable

jakewtorres and ehoffman

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.

Anonymous
Not applicable

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

0 Likes

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.

jamesle1 jakewtorres j.t

JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

Hi tdsweete,

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.

Jacob

0 Likes
Anonymous
Not applicable

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.

print_005.bmp

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

0 Likes
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

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.

Jacob

0 Likes