- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
On a custom board with a 20732S module that I have been developing on for some time, the module was seen via HCI debug to keep entering reset automatically. Now it is completely unresponsive and no debug traces are outputted and the program is not able to be downloaded. My other modules work great w/ same code/methodology. What could be the issue?
I checked the download.log file and it states"Error processing command-line arguments: Unexpected argument 115200". (which i'm assuming is referring to the baud rate?)
If more information is needed, please let me know. Thanks
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I couldn't resolve this issue, so I moved onto another dev. board we had.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Q1) Do you have any other 20732S boards that have the problem of continually resetting?
Q2) On the board that is un-responsive, can you put an O-Scope on the UART_TX pin to capture what the 20732S is trying to "say" during programming?
Stated differently. During the download of the new image via the SDK, there is a communications protocol back and forth. You will be able to see where the host wiggles the UART_RX pin when talking to the 20732S at the beginning of the program session.... I want to see if the 20732S is responding in any way on the UART_TX line.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A1) My other 20732S boards do not have this problem.
A2) THe board now seems to be 'dead' (traces don't show up anymore, the reset LEDs don't flash like before, reset pin does not elicit a response, SDK does not recognize the device). It is only if I unplug and re-plug in the battery will then the module be recognized and try to download (but still fail).
When I probe it, I get something like this before the download fails....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nice picture and helpful.
Please change your sweep-time from 5mS to 10uS and give me a couple more "close-ups".
The UART pin is a digital I/O and should get driven fully high/low. I am looking for instances where pulses aren't driven fully high, or have really long rise times when going from low to high, or vice-versa. Kind of like what you show at the start of the 3rd division (past the center-line) on your capture.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Corrupt EEPROM?
Within Appendix E of the Quick Start Guide, there is a procedure for "Recovering A Corrupted WICED Smart Tag"
WICED Smart Quick Start Guide (SDK 1.x and TAG2 Board)
You may want to try this as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To confirm, when I am pressing the Boot ROM button, that means connecting the SDA line to 3.3V?
It seems like I get something new every time. Did you really want 10uS? It would only show one pulse then.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello mochi,
Are you still struggling with these boot issues?
Please let us know.
Thanks,
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
JT - the problem (corrputed waveform on UART_TX) reported in this issue by mochi are eerily similar to the problems reported over here BCM20732S based boards sometimes develop UART failure by ldgirod.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I couldn't resolve this issue, so I moved onto another dev. board we had.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi mochi,
1. Do you have the lot-code of the module on the failing board?
2. Were you using an FTDI cable / device during programming or some other (USB<->UART) mechanism? What voltage cable?
3. Am I reading the waveform correctly? The signals show ~5volt rail whereas the device is only rated at 3.3 volts.