Programming the BCM20736S on a custom PCB

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

cross mob
Anonymous
Not applicable

I have a similar problem to this:

Re: Information: Programming your BCM20732S-based board from an onboard UART header

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.

0 Likes
1 Solution
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

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).

View solution in original post

0 Likes
41 Replies
Anonymous
Not applicable

Your problem is that both the internal and external EEPROM have the same address. If you have all three chip-enables tied to ground, then there is an i2c bus conflict as both EEPROMs will respond.

So for now you do need to remove the external EEPROM, and then you need to re-design the HW to make sure the external EEPROM has a different i2c address so it can be individually addressed

Anonymous
Not applicable

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.