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
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?
Seriously... I don't understand having tech support on a forum if nobody from Broadcom will even read and reply to my question!
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.
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.
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.
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.