Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
I am starting a new thread because it is for the BCM20736S. Here it goes:
I built a board for the BCM20736S and the board seems functional. I built it up, it powers on, and I can see a factory pre-programmed 'Hello' application running from my iPhone using LightBlue. I can interact with the services and characteristic and read the manufacture string.
I am trying to program this board with other apps using both the WICED SDK 2.0 virtualized in Windows XP and natively on Mac OS X. Neither seem to be able to program the board. I know my TX/RX lines connected correctly because I can see debug information over my FTDI breakout board from factory-programmed sample app.
I have not taken any scope captures yet of RX/TX or SCL/SDA.
1. P1 is pulled high with a 10k Pull-up.
2. UART_RX (pin 18) is pulled high during power-up. (I can still see the hello application on my iPhone even when I do this)
3. UART_TX is on pin 19.
After power-up, I let UART_RX float or pull it low. I then press the reset button and double-click a sample app and to program/upload code. It always fails to detect the BCM20736S. Obviously it is working so I am not sure why I can't program. What am I doing wrong?
I have test pads/break outs on all I/O's so I can probe anything needed.
The pullup on the HCI UART RX line should cause the part to come up in prgramming mode.
If you can still see the app advertising with RX pulled high, then something isn't right.
Note that the the download tools leveraged by the SDK havenot been tested with a VM. One thing to try is to find out which serial port the device is connected to and then use a terminal-like app (teraterm/hyperterm) to open the port on the host OS, then power cycle chip and disconnect the terminal app (so when 2073x boots up, we know that the host is driving its TX line high – not sure if a VM would do this).
Ultimately, we want the host to drive its TXd (2073x’s RXd) high (not just a pull-up).
Nsankar, thanks. it looks like you are correct. I found a document that shows the BCM20726S module with an internal memory chip on i2C address 000. same address as the external chip in our custom circuit. This is clearly wrong, and it seems very likely the problem causing the CRC error during download. The hardware team says they can cut and jump a new address into the external chip and I'll try programming it. Will be a couple of days or three but I will report back and hopefully this will answer the thread.
Thanks all for your responses. appreciate the help and/or moral support. It's been a frustrating couple of weeks on this but on the bright side I've learned quite a bit.