How to program the 20732 (not module)?

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

cross mob
Anonymous
Not applicable

I have just got back a couple of boards built around the BCM20732 chip (not the module) and am having a little trouble programming the chip. I have a tried a number of ways including using the method suggested on this forum, using cgs.exe and ChipLoad.exe. I am using the following cable to program the chip using HCI UART: (http://www.digikey.com/product-detail/en/TTL-232R-3V3-2MM/768-1095-ND/2507857)

I guess one of the questions that keeps coming up within me is whether or not the EEPROM is required to run my application code? I have not included either an external EEPROM or any serial flash memory, is this required?

If not, which would be a huge relief, how do I go about programming the board? It seems the WICED IDE and even the ChipLoad is set up to program directly to EEPROM, as they are looking for it. Is there another software tool that would allow me to this?

Any help would be much appreciated.

Gurpal

1 Solution
Anonymous
Not applicable

Hello J.T. and Broadcom Forum

This is becoming increasingly frustrating and I am running out of time. Here is a summary of where I am.

1. I think we all agree my schematics are fine since they replicate the TAG board.

2. I can successfully program the TAG board but I cannot program my board.

3. I only have the Broadcom recommended EEPROM on the my board connected to the I2C (Pin 15 and Pin 16). I had a Real TIme Clock, but with and without the Real Time Clock I see the same thing. .

4. When my board powers up, SDA and SCL go low, but for I2C I would expect them to be pulled up.

5. I can see the activity on SDA and SCL and there is communication between the 20732 and the EEPROM. At the end of the boot sequence it looks like the 20732 goes in the SPI mode. I have sent in a zip file with details of this communication on April 1.

6. If I program a EEPROM on the TAG board,and place on my board, my board boots up fine in application mode (and runs the application as expected) but I still cannot program it. Same result.

I think the easiest thing is for someone at Broadcom to look at the file I attached that shows the SDA and SCL communication during boot and analyze the results. Is that possible? Since, this appears to be a boot up issue.

Right now, I am programming the EEPROM using the TAG board, then moving the EEPROM to my board and running in application mode. But this is not a good solution. 

Thanks,

Gurpal

View solution in original post

0 Likes
43 Replies
Anonymous
Not applicable

Here is my understanding.

BCM20732 SoC doesn't have NVRAM. So it can't be programmed.

You should connect an EEPROM/Flash and then your application can be programmed into it.

BCM20732S module includes 64KB EEPROM.

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

Within the TAG Board Environment, the EEPROM includes BD ADDR (Bluetooth Device Address), Patches and Bonding/Pairing information.

It's also the NVRAM where your program is stored during development with the TAG board.

So your application loads into RAM on the 20732 during execution, but to get here, the SDK first downloads a minidriver to RAM on the 20732, then pushes the code over the HCI uart to the minidriver which will then write to EEPROM.

0 Likes
Anonymous
Not applicable

Thanks for the quick response guys.

I was hoping that wasn't the case, since we got the boards back. So I would just like to get things straight I have a couple questions:

1. Which EEPROMs should I target to get? I assume the ones suggested on the datasheet are good.

2. In the programming sense, once the EEPROM is added to I2C line, the WICED IDE should work as it does with the Tag Dev board, right? Assuming I have the same setup as the dev board - ftdi chip and USB connection.

Otherwise, using the cable listed above, the Soc should be programmed using the cgs and chipload programs?

Gurpal

0 Likes
Anonymous
Not applicable

Hello Gurpal,

Answers:

1.  Yes, The Microchip parts are the ones that we usually use.

2.  Yes, if you used the TAG board as a guide, you should be able to program using the cgs adn chipload programs.

3.  Please see Re: BCM20732S refuses to program for a guide to using the cgs and chipload program.

4.  I believe the cable mentioned above is the same FTDI chip we used on our boards - FT2232HL

Please let me know if you have further questions.

JT

0 Likes
Anonymous
Not applicable

Thanks for the response and your answers JT.

So if I turn the switches on the tag board off (connecting UP_RX/UP_TX and RX_EXT/TX_EXT) I should have a similar set up as my board, without the FTDI chip on board.

Then, hypothetically, if I use the FTDI cable and connect the RX/TX pins to UP_RX/UP_TX I should be able to program the tag board with the same method described in the guide you mentioned above, right?

Gurpal

0 Likes
Anonymous
Not applicable

Hello Gurpal,

Do you have a 10K Pull Down on UP_RX?R3_PullDown.PNG

0 Likes
Anonymous
Not applicable

Yeah we have a pull down on that pin.

Screen Shot 2014-03-28 at 5.18.17 PM.png

0 Likes
Anonymous
Not applicable

Yes, it should work.

Let's give it a try and let me know!

JT

0 Likes
Anonymous
Not applicable

This is the jumper we have on the board, which connects to the FTDI cable

Gurpal

0 Likes
Anonymous
Not applicable

Did you try it yet?

0 Likes
Anonymous
Not applicable

I will be, just getting a hold of one of the EEPROMs listed on the datasheet.

Is there any other component that the chip requires to program/run?

0 Likes
Anonymous
Not applicable

I tried to program, here is the response:

ChipLoad-Failure.PNG

It started and looks like it wrote quite a few bytes, but the percentage never increased from 0.0% and then eventually terminated with error. I will keep trying, any other hints/suggestions that might help?

Thanks,

Gurpal

0 Likes
Anonymous
Not applicable

You're right.  It didn't work.  Let me check with my team.

0 Likes
Anonymous
Not applicable

Did you create the hex file and load it as shown in: Re: BCM20732S refuses to program

JT

0 Likes
Anonymous
Not applicable

Yeah, I tried converting the cgs file with the prompt and also directly using the hex file form the build folder, still no go.

0 Likes

Is the write protect pin on the EEPROM connected to P1 or GND?

0 Likes
Anonymous
Not applicable

we have it connected ground. we have no more GPIO pins available

0 Likes

When calling chipload.exe, use the -LOGTO option to log the entire download process to a file. Something like this:

chipload.exe <ALL_OTHER_DOWNLOAD_OPTIONS_YOU_GENERALLY_USE> -LOGTO <path/to/log/file.log>

Then paste the last 50 or so lines from this log.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

So I have been trying with the FTDI cable and I think I know where the problem is. I am using the following EEPROM, which I believe is one of the recommended EEPROMs from the 20732 datasheet.

http://www.xilinx.com/products/boards/ml505/datasheets/6485.pdf

I have it hooked up as follows:

PINS 1-4 - GND

PIN 5 - SDA
PIN 6 - SCL

PIN 7 - GND (WP)
PIN 8 - VCC

Currently I am using pull-ups of 1k, due to the chip we are using on I2C. Would that work?

I am using a Salae Logic Analyzer, if I send you the session, would you be able to open it?

I have attached the log file from the attempting programming session.

Gurpal

0 Likes

Yes, I will be able to open a salae logic analyzer capture.

0 Likes
Anonymous
Not applicable

We are finding that after reset, the I2C pins (SDA/SCL) are being driven low, I would expect them to be high as we have 1k pull-up resistors. Only the EEPROM is on the I2C bus.

When we disconnect the EEPROM from the bus, the pins are still low.

Any suggestions?


Gurpal

0 Likes
Anonymous
Not applicable

While debugging our board, we have noticed the chip must be pulling the I2C bus low. When holding the chip in reset, the I2C pins are pulled high through the pull-up resistor; however immediately after reset, the I2C pins are being forced low. I have attached a screenshot of the I2C lines during programming, as you can see the I2C lines are held low.

I2C_screenshot.png

We've checked the board layout, and don't see any problems, our schematics are identical to the Tag Board's, except we are using 3.3V instead of 1.8V to power the chip.

Gurpal

0 Likes

The chip does not drive I2C pins low unless it is trying to read something, and only during the 0 bits (floats the bus for 1 bits for the pull up to pull high). How is the address of the EEPROM configured? The 20732 expects it to be 7-bit 0x50 (0xA0/0xA1 on the bus for write/read).

0 Likes

Regarding your question about how the chip knows to run pins 15/16 in I2C mode, you said that the the frequency you are seeing on the clock (pin 16) is around 8MHz, which you thought meant the pins were in SPI mode instead. You went on to ask if there is a way to make sure the part is in I2C mode.


I ran this past the internal team and they said that 8MHz does not sound right.

At boot, the ROM looks for I2C EEPROM first. So it will configure these two pins for I2C, set speed to 100 KHz, send out a very slow EEPROM reset sequence (start, start, 9 clocks with SDA held high, start, stop – this special sequence is in most EEPROM data sheets). Then it will write 0x00 0x00 to I2C slave 0xA1. If there is no acknowledgement, then there is no I2C EEPROM connected, so it will reconfigure the pins for SPI at 12MHz (along with P32 and P33 for MISO and CS, the default speed is 12MHz, which is why they are suprised to see 8Mhz) and try to read status register from an SPI SF if its connected.

So essentially, if the FW tries to detect the type of NV connected automatically and if an NV is found, then the pins will get assigned either I2C or SPI function mode until power down.

0 Likes
Anonymous
Not applicable

Are the UP_TX and IP_RX pins used like UART pins or are they translated into SWCK and SWDIO ?

If so can any JTAG debugger that supplies SWCK and SWDIO be used?

0 Likes
0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

That's what I thought about the frequency also.

I have attached the logic data for the programming session. On top is the UART communication and Channels 4/5 show the I2C communication. Both pins are driven low for some reason, even with pull-up resistors.

As you can see, there are two different clock frequencies during the communication, 8MHz first and then 187.5 kHz, which is probably around the right frequency to operate at.

Please let me know your thoughts. I have also attached the datasheet for the serial EEPROM we are using.

Gurpal

0 Likes

128 Kbit EEPROM is too small – that’s only 16 Kbytes.

I believe our current patches (EEPROM is used for patched) + the app is over this limit. This could be a problem as well.

0 Likes
Anonymous
Not applicable

But that is the one that is recommended on the BCM20732 datasheet, unless I'm mistaken.

Screen Shot 2014-04-01 at 2.29.05 PM.png

0 Likes
Anonymous
Not applicable

Hello Gurpal,


Regarding your schematic, the 15pF associated with the 24MHz xtal appears to be too high of a value?

Our recommendation for these caps is 12pF and 15pF (and perhaps even 10pF in some cases).

Also, try to disconnect the SCL and SDA lines and see if you are still getting issues.

JT

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

It's strange you say that because we followed the schematic exactly in terms of the crystal. I believe we even used the same manufacturer we found on the BOM.

Screen Shot 2014-04-01 at 4.07.16 PM.png

Also, we tried disconnecting the EEPROM, so there is nothing on the I2C bus, and we still have those lines being pulled low. If the chip is held in reset, then the pins are driven high.

Michael mentioned at boot up the ROM looks for the I2C, so I monitored this and it looks like that is exactly what happens. I have attached a Salae Logic data file, can you tell me if this communication is correct? After that little bit, the I2C pins are driven low.

Gurpal

0 Likes
Anonymous
Not applicable


Hello Grupal,

You are correct on the 15pF - sorry, I was looking at an internal board.

Let us examine your I2C data with our internal team.

JT

0 Likes
Anonymous
Not applicable

Hi JT,

I also monitored the communication between the 20732 and EEPROM on the Tag Board, and the bytes which are read from the EEPROM are different then what we are seeing on our board. Does the EEPROM need to be pre-programmed with anything? Since we are not using the module, any EEPROM should suffice, correct?

Gurpal

0 Likes

The EEPROM does not need to be pre-programmed with anything. The boot ROM looks for a specific sequence of bytes in a number of locations and if none of these are valid, it will enter download mode. Since you are able to download the minidriver, you are way past boot.

0 Likes
Anonymous
Not applicable

So if none of the bytes that are read are valid, do those pins go into SPI mode? Because towards the end of that communication sequence, the clock frequency changes from 100kHz to 12MHz. Then after both lines are held low as you might expect in SPI communication.

0 Likes
Anonymous
Not applicable

I have tried a couple of things now to try to understand exactly what the problem is, I also replaced the EEPROM on the Tag Board with one I ordered from Mouser: 24AA128

http://ww1.microchip.com/downloads/en/DeviceDoc/21191s.pdf

Pretty much got the same response, except the bytes being read from the EEPROM were different, but the lines remained high after the 10ms sequence.

With everything I tried I can't seem to understand why the I2C pins remain low, which I think is the reason why the programming stalls when the chip needs to write to the EEPROM. If you guys can please suggest something I should try or be doing, I really need to be able to program this chip.

I am thinking of switching the 20732 chips around from the Tag board to our board, do you think that might allow me to program our board?

Gurpal

0 Likes
Anonymous
Not applicable

Hello Gurpal,

I have been studying the schematic and here may be a few trouble shooting steps you might try:

  1. What about the TP1 and TP2 near the RST_N lines? Could there be a possible short?
  2. Are you able to disconnect the RTC and find out if you still have the same problem?

We are still looking to see what the problem might be.

JT

0 Likes
Anonymous
Not applicable

Hi JT,

Thank for the steps you mentioned.

1. I have taken a look at TP1/TP2 and verified there is no short, we have actually been using those to reset the chip.

2. We have taken off the RTC and still see the I2C pins being driven low, so only the BCM20732 is connected on the bus.

We also tried the following:

     a. Programmed the Tag Board

     b. Removed the EEPROM from the Tag Board

     c. Placed a new EEPROM (same model/memory) on the Tag Board

     c. Connected the original EEPROM to our board, through the I2C pins

This way, when we ran the application on the original EEPROM with our board, the program came up just fine. We are able to connect to it through Bluetooth and see all of the services.

Now when we try to program the Tag Board, it is unsuccessful from the WICED program. We can see the communication between the chip and the EEPROM, but it doesn't write the program to the EEPROM.

This makes me think that something specific is on the original EEPROM that the 20732 is looking for, because any other EEPROM will not allow the application firmware to be programmed. Any thoughts on this?

Gurpal

0 Likes
Anonymous
Not applicable

Sorry correction, I am able to program the Tag Board with the new EPPROM, it seems I had the switches on SW4 in the wrong direction.

However, I am still unable to program our board with the original Tag Board EEPROM; even though I can run the application that is already on the EEPROM.

Do you think it has something to do with P1 not being connected to WP? Does the minidriver/20732 chip require the ability to pull WP high and disable writing to the EEPROM during programming?

0 Likes