cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

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
Reply
1 Solution
Moderator
Moderator

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
Reply
41 Replies
Moderator
Moderator

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
Reply
Anonymous
Not applicable

Can you put it in programming mode with pulling P0 high? Are there other ways I could test the RX/TX pins to make sure the pads are soldered on correctly?

I built up the board in a toaster oven and don't want to reflow again until I check all other possibilities. Again, the chip is powering up and I can see the Hello application on my iPhone that seems to be pre-loaded.

Thank You,

George

0 Likes
Reply
Moderator
Moderator

I checked with the developers and unfortunately, the previously described method is the only one available.

0 Likes
Reply
Anonymous
Not applicable

On a board I have programming I am facing this error. When I reset it, it still doesn't program. This board was previously programming.

Creating OTA images...

Conversion complete

OTA image footprint in NV is 3841 bytes

Detecting device...

Device found

Downloading application...

****Download failed - Press the reset button on the device and retry ****

0 Likes
Reply
Anonymous
Not applicable

http://embedded.cdistore.com/datasheets/embedded/EMRF-20736S-BOB%20Datasheet.pdf

I am using a board built off this schematic. It has no UART pull-up that I can see and seems to use P0 from experimentation to get into programming mode. Is this not officially supported?

0 Likes
Reply
Anonymous
Not applicable

Hi George,

  The HCI_RX line is the key line to pay attention to.  The module has an internal Pull-Down on the HCI_RX line.  So if you connect your board to a USB-UART device it will inevitably have a pull-up that will pull the HCI_RX and HCI_TX lines high.  For the device to be programmed the HCI_RX line MUST be HIGH or Connected to the USB-UART_TX line.  After the device has been programmed you should disconnect the HCI_RX from the USB-UART_TX line and then RESET the module.  This will put it into Application Mode and you can view the Debug Output.

Just so you are clear there is no pre-programmed application that comes programmed in the module.

Regards,

Frank

0 Likes
Reply
Anonymous
Not applicable

Hi Frank,

Thanks for this explanation. So the button on P0 has nothing to do with the programming functionality--to be clear?

About the pre-programmed application: I received samples. The module definitely has something on it as I have never programmed it. It comes up with the hello application. I can send you some screenshots from my iPhone if you would like to see. Do you know why this could be?

With the board I have from Embedded Masters I am unsure why the board is being detected but not programming. Do you know? Have you seen this? I push the reset button and retried to no avail.

Thanks,

George

0 Likes
Reply
Anonymous
Not applicable

What I am getting when I program the Embedded Masters board:

Creating OTA images...

Conversion complete

OTA image footprint in NV is 3841 bytes

Detecting device...

Device found

Downloading application...

****Download failed - Press the reset button on the device and retry ****

0 Likes
Reply
Moderator
Moderator

There is detailed description here of how P0/RESET works on the TAG2/3 boards: Re: BCM20732S refuses to program

You do not need this switch in a production design.

As Frank mentions, the state of the HCI_RX line is critical when the device initially comes up as that determines whether or not it will come up in Programming/Application mode.

I will need to ask the manufacturing team about whether or not an application is loaded by default onto the module.  The answer used to be NO, but you are the second user that has determined there is indeed an app running on the module from the factory.

nsankar arvinds

0 Likes
Reply
Anonymous
Not applicable

Yes - all modules are pre-programmed in the factory with a test application and this is the default state in which the modules are delivered to customers. This test application is only used for RF testing in the factory production line - but as user have experienced - this application is a very simple BT Smart application.

Anonymous
Not applicable

Hey George,

  Check out the latest documentation for the EMRF-20736S-BOB it is rather comprehensive and covers the HCI_RX/Programming in good detail.  The module may have had something programmed into it as a means for them to do functional testing.  I am sure the cause of programming issues is still to do with the HCI_RX line and ensuring after you have either connected this to the USB-UART_TX line you have to hit RESET for the BCM20736S to register the change as it reads the HCI_RX line after every POR/RST event. 

Regards,

Frank

0 Likes
Reply
Anonymous
Not applicable

So far all the replies to this thread seem to ignore the fact that the device is in fact in programming mode as evidenced by the download in progress.  The failure comes at the end after the download where the SDK says "Download Failed'... this is after the device is recognized and the program has been downloaded.  What does it mean when it fails at this step.  Surely we can surmise that the RX Line was not the problem since the SDK proceed with the download.

0 Likes
Reply
Anonymous
Not applicable

In the build directory - there should be a download.log

Can you please share the log?

Anonymous
Not applicable

Thank you. I was not aware of the download log.  It is very revealing.  There seems to be only one.  This one is from 3am today and must have been my last attempt of the night.

At the end it has a CRC error.  Interesting. I wonder what that could be all about?  Maybe my cable is too long and the data is ratty??  It says: "CRC mismatch while checking 40 bytes starting at address 0xFF000000; host computed 7BD66B74, firmware computed 8CD04C73"

Here is the tail end of the download log before the fail...

Download minidriver successfully had written 251 bytes to address 0x0020305B

Download minidriver successfully had written 251 bytes to address 0x00203156

Download minidriver successfully had written 251 bytes to address 0x00203251

Download minidriver successfully had written 251 bytes to address 0x0020334C

Download minidriver successfully had written 251 bytes to address 0x00203447

Download minidriver successfully had written 251 bytes to address 0x00203542

Download minidriver successfully had written 251 bytes to address 0x0020363D

Download minidriver successfully had written 251 bytes to address 0x00203738

Downloaded 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%). Verified 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%). Current state: Executing -- loading minidriver

Download minidriver successfully had written 251 bytes to address 0x00203833

Download minidriver successfully had written 251 bytes to address 0x0020392E

Download minidriver successfully had written 251 bytes to address 0x00203A29

Download minidriver successfully had written 251 bytes to address 0x00203B24

Download minidriver successfully had written 21 bytes to address 0x00203C1F

Download minidriver successfully had written 8 bytes to address 0x002043FC

Launch minidriver at 0x00201000 succeeded

Chip erase in progress

Downloaded 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%). Verified 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%). Current state: Executing -- erasing chip

Download config successfully had written 40 bytes to address 0xFF000000: 01 08 00 F0 00 00 62 08 C0 5D 89 FD 04 00 FF FF FF FF 40 06 00 A3 02 1B 6A 73 20 02 0A 00 80 05 00 00 40 01 00 00 00 04

Downloaded 0 code bytes ( 0.0%) and 40 data bytes ( 0.6%). Verified 0 code bytes ( 0.0%) and 0 data bytes ( 0.0%). Current state: Terminated with error

 

A total of 1 contiguous memory areas were filled:

[FF000000..FF000027] DATA (40 bytes)

CRC mismatch while checking 40 bytes starting at address 0xFF000000; host computed 7BD66B74, firmware computed 8CD04C73

0 Likes
Reply
Anonymous
Not applicable

It is possible that either the EEPROM is bad for some reason or yes you are having data corruption on the download.

Try another cable or if you have another board you can try that as well.

Basically from the log the driver was downloaded to RAM correctly and is running but when downloading the actual patch and application code to the EEPROM it is getting errors on the write and mismatch.

Anonymous
Not applicable

Thanks!  I have two boards from the recent PCB build and they both show the same results.  This is a new circuit and this is the first try so it is possible that something is wrong with the circuit as well.  I will rework my cable and try again.  It is really two cables spliced together.  Is it possible a bad solder can cause data corruption?  I'm basically a software guy so my soldering is not the greatest.  maybe crimps would be better.

It looks like this from the other log says that the first block of memory was written, but then the next block failed on the write.  If there was a write protect issue I suppose the first block would have failed also.

2014-12-07@03:00:37.697 Received bytes from HW:

7 bytes: 04 0E 04 01 4C FC 00

2014-12-07@03:00:37.697 Download minidriver successfully had written 251 bytes to address 0x00201000

2014-12-07@03:00:37.697 Sending bytes to HW:

259 bytes: 01 4C FC FF FB 10 20 00 E7 36 48 03 68 00 2B 07 D1 3A 48 03 88 00 2B 03 D0 3A 48 03 68 31 48 03 ...

2014-12-07@03:00:39.647 ERROR: Download minidriver error trying to write 251 bytes to address 0x002010FB

0 Likes
Reply
Anonymous
Not applicable

Could be cable related

Unless there was some Manufacturing issue and the hardware was damaged

Naren Sankar

Broadcom Corporation

Anonymous
Not applicable

Also, in another log file.  the "release.log" there is this which shows an error writing to memory...

2014-12-07@03:00:37.619 Will be downloading 0 bytes of code and 7001 bytes of data using minidriver Platforms/BCM920736TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex

2014-12-07@03:00:37.619 BTP file: Platforms/BCM920736TAG_Q32/20736_EEPROM.btp

2014-12-07@03:00:37.619 The config data is coming from the following files

2014-12-07@03:00:37.619 build/heart_rate_monitor-BCM920736TAG_Q32-rom-ram-Wiced-release/heart_rate_monitor-BCM920736TAG_Q32-rom-ram-Wiced-release.hex

2014-12-07@03:00:37.619 Sending bytes to HW:

4 bytes: 01 03 0C 00

2014-12-07@03:00:37.650 Received bytes from HW:

7 bytes: 04 0E 04 01 03 0C 00

2014-12-07@03:00:37.650 Sending bytes to HW:

259 bytes: 01 4C FC FF 00 10 20 00 10 B5 81 B0 73 48 00 F0 E3 F8 00 23 72 49 0B 60 72 49 0B 60 00 F0 EF FB ...

2014-12-07@03:00:37.697 Received bytes from HW:

7 bytes: 04 0E 04 01 4C FC 00

2014-12-07@03:00:37.697 Download minidriver successfully had written 251 bytes to address 0x00201000

2014-12-07@03:00:37.697 Sending bytes to HW:

259 bytes: 01 4C FC FF FB 10 20 00 E7 36 48 03 68 00 2B 07 D1 3A 48 03 88 00 2B 03 D0 3A 48 03 68 31 48 03 ...

2014-12-07@03:00:39.647 ERROR: Download minidriver error trying to write 251 bytes to address 0x002010FB

0 Likes
Reply
Anonymous
Not applicable

Having a similar problem to the one mentioned at the top of this thread...  programming custom device I get:

Detecting device...

Device found

Downloading application...

****Download failed - Press the reset button on the device and retry ****

When this happens to me I see the following on the scope. (TX on top RX on bottom)

This is during "Downloading application..."

Then after the download appears to stop I get a pause and then "Download failed - Press the reset..."

Programming BCM20736S.jpg

When I press the rest button the same thing happens again.

I tried Recover mode and  I get a similar result, and in the end it says " Recover Failed..".

What is causing the failure?  The device is in program mode and appears to accept the program blocks (lower trace) and after each block there is a blip on the upper trace that I assume is some kind of 'ack - ok send next block' coming from the BCM20736S.

What does it mean when the download appears to progress but then it says 'failed'  I understand there is some verification step at the end, but what does the verification consist of and what can cause it to fail?

0 Likes
Reply
Anonymous
Not applicable

Hi All,

I have briefly looked over this section but was curious if you have tried 'recovering' the platform? I noticed some chat about it but it didn't seem clear if it was instruction to hold SCL (it could be SDA, if SCL doesn't work but pretty sure it is SCL) high was given. The sequence to properly recover the chip goes like this:

1. Hold SCL high

2. Press Reset button

3. release SCL

5. initiate recovery by going into WICED SDK and in the Targets pane change "download" to "recover" similar to the image attached.

Screen Shot 2014-12-11 at 6.24.47 PM.png

This process should overwrites the EPROM that stores the bootloader that loads when you reset the device in programming mode.

Best of Luck,

George

0 Likes
Reply
Anonymous
Not applicable

Hi George, thanks for the feedback.  I was not aware of the requirement to hold SCL high or do anything with SCL and SDA to do the recovery.  I have tried recovery mode and it also fails just like download with a CRC error.  We are using the BCM20736S 'module' which has it's own memory chip internal to the module.  Our external memory chip is placed on the SDA and SCL pins coming out from the module.  I have seen no documentation on this but from you and maybe one other post it sounds like there could be a conflict here between our external memory and the broadcom module's internal memory chip.  I will investigate your question on addressing.  I don't know the answer offhand and probably need to read the datasheet to even know how to answer it.  I did not design the circuit, but just assumed that the external memory would be seen as a separate device, and not in the same memory address space as the module's memory.  There is not much documentation on this that I can see.

Thanks,

Eric

0 Likes
Reply
Anonymous
Not applicable

I tried multiple cables and multiple PCBs.  All with same result.  Recover and Download fail with memory write errors.  What type of manufacturing issue could damage the hardware to result in this error?  What possible schematic errors can result in this error?  Am I the only person who has ever experienced this error?  I need to resolve this problem quickly.  We only built a dozen or so of these on the first spin.  I can try more units but what if they are all the same... then I have learned very little.  If one of 10 works then we have a serious yield problem but at least that would be progress.  I would like to have more detailed analysis by Broadcom of where this error comes from, why it was able to write the first block of 251 bytes but not the second.

I am now using the FTDI 3.3V USB to UART cable and having better luck, but now stuck with 'Recover Failed".  Also download fails with the same errors.  Seems to be receiving the program but unable to write it to memory.  Need help.  This a major roadblock to progress and my time is running out on this project.

2014-12-07@03:00:39.647 ERROR: Download minidriver error trying to write 251 bytes to address 0x002010FB

Below is the output from the log file.  Note the last line ... error writing to memory.   Please help. anybody...

2014-12-07@03:00:37.619 Will be downloading 0 bytes of code and 7001 bytes of data using minidriver Platforms/BCM920736TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex

2014-12-07@03:00:37.619 BTP file: Platforms/BCM920736TAG_Q32/20736_EEPROM.btp

2014-12-07@03:00:37.619 The config data is coming from the following files

2014-12-07@03:00:37.619 build/heart_rate_monitor-BCM920736TAG_Q32-rom-ram-Wiced-release/heart_rate_monitor-BCM920736TAG_Q32-rom-ram-Wiced-release.hex

2014-12-07@03:00:37.619 Sending bytes to HW:

4 bytes: 01 03 0C 00

2014-12-07@03:00:37.650 Received bytes from HW:

7 bytes: 04 0E 04 01 03 0C 00

2014-12-07@03:00:37.650 Sending bytes to HW:

259 bytes: 01 4C FC FF 00 10 20 00 10 B5 81 B0 73 48 00 F0 E3 F8 00 23 72 49 0B 60 72 49 0B 60 00 F0 EF FB ...

2014-12-07@03:00:37.697 Received bytes from HW:

7 bytes: 04 0E 04 01 4C FC 00

2014-12-07@03:00:37.697 Download minidriver successfully had written 251 bytes to address 0x00201000

2014-12-07@03:00:37.697 Sending bytes to HW:

259 bytes: 01 4C FC FF FB 10 20 00 E7 36 48 03 68 00 2B 07 D1 3A 48 03 88 00 2B 03 D0 3A 48 03 68 31 48 03 ...

2014-12-07@03:00:39.647 ERROR: Download minidriver error trying to write 251 bytes to address 0x002010FB

0 Likes
Reply
Moderator
Moderator

jose.raffucci nsankar 79rpm ed-falsetti j.t ahunter

I seem to recall a similar problem here: Re: Unable to (re) program BCM20736

I believe what was being said here was that this is a device where the firmware DOES need to receive a DOWNLOAD_MINIDRIVER command at the beginning of the download, but the CHIPLOAD is being called with  -NODLMINIDRIVER option telling it not to issue this command. In other words, this option needs to be removed from the CHIPLOAD invocation.

Are you using the SDK for programming, or chipload through the command line as you were originally doing when you started with the TAG board?

If through the command line, the thread noted above contains instructions.

If through the SDK, I believe the parameter needs to be entered as an option within the make file.

0 Likes
Reply
Anonymous
Not applicable

Thanks all.  Regarding the Minidriver... I checked my chipload command (from the SDK Makefile) and it appears the -NOMINIDRIVER switch is not present, which is good.  Also, from the download log it appears the minidriver is downloaded and working when the CRC memory error occurs.  Here is the console output on the chipload:

Tools\ChipLoad\Win32\ChipLoad.exe -BLUETOOLMODE -PORT COM14 -BAUDRATE 115200 -MINIDRIVER Platforms/BCM920736TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex -BTP Platforms/BCM920736TAG_Q32/20736_EEPROM.btp -CONFIG build/heart_rate_monitor-BCM920736TAG_Q32-rom-ram-Wiced-release/heart_rate_monitor-BCM920736TAG_Q32-rom-ram-Wiced-release.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/heart_rate_monitor-BCM920736TAG_Q32-rom-ram-Wiced-release/download.log 2>&1 && "Tools/common/Win32/echo.exe" Download complete && "Tools/common/Win32/echo.exe" && "Tools/common/Win32/echo.exe" "Application running" || "Tools/common/Win32/echo.exe" "****Download failed - Press the reset button on the device and retry ****"

Downloading application...

****Download failed - Press the reset button on the device and retry ****

ltokman

0 Likes
Reply
Anonymous
Not applicable

ehoffman

Have you tried to reset the chip?  Re: Unable to (re) program BCM20736

How's your power source?  Is it possible you're dipping it when attempting to commit it?

Are you super-duper sure that the EEPROM WP is pulled up for the duration?

Have you tested your cable with a known good board (TAG board)?

I can't get past the fact that you see the device when it should be in programming mode.  It should not be advertising so either the FW is off in the weeds or it's in app mode.

Anonymous
Not applicable

ehoffman

Just wondering - do you have any other device connected to the i2c bus on your custom PCB?

Anonymous
Not applicable

And since you have sourced and built actual hardware - you can also request the Broadcom distributor and/or rep that you worked with to get the BCM20736S to help you troubleshoot this case or ask for factory help

Anonymous
Not applicable

Yes thanks.  We have initiated that process and have a name of FAE or FEA (?) to contact.  He is on the road today but hopefully will see email tomorrow.

0 Likes
Reply
Anonymous
Not applicable

Yes, thanks for asking.  We have an external memory chip connected to the SCL and SDA lines. 

Other than that we have only an ADC on the SPIFFY interface.

0 Likes
Reply
Anonymous
Not applicable

Do you know what the address to that external memory chip is? It could conflict with the internal one that stores the bootloader...

Anonymous
Not applicable

Gmelcher, I don't know what the address is on the external memory chip.  I will investigate.

Thanks for the tip.

0 Likes
Reply
Moderator
Moderator

Pin 21 SCL is shared with SPI_1 SCLK
Pin 22 SDA is shared with SPI_1 MOSI

So SPI_1/SPIFFY1 is not available on the SIP module as those pins are tied up by the internal EEPROM.

Do you have the external memory device on the same bus as the internal EEPROM?

I'm not aware of anyone else that has successfully used external memory on the SIP module

Anonymous
Not applicable

Thanks mwf_mmfae,   We are using SPIFFY2 (not 1) in our App code.  There is an external EEPROM on the SCL and SDA pins.  It's a 64K EEPROM with the three address pins set to ground.  We did not intend for it to participate in any download/programming activity, but perhaps there is a conflict there.  It seems these pins are on the same I2C bus that is used for download/programming.  79rpm is working with us now to help isolate the problem.  He will inspect our schematic this afternoon.  If it turns out the external memory is the issue I can have the hardware team pull the memory chip off the boards I'm working with and try downloading again.  Out App will still work without the external memory.  It is there to store data during temporary disconnects with the host but the feature is easily disabled in the App code.

0 Likes
Reply
Anonymous
Not applicable

Thanks.  I may have confused you by saying "see the device"..  What I meant was the SDK recognizes the device on the programming cable and is kind enough to send the program/data to it.  I didn't mean that it was advertising.  I would be thrilled if it was. 🙂  The cable I am using is a FTDI 3.3V USB to UART cable.  I think the voltage is fine and have measured it at 3.3 volts.  When trying to program the device via the TAG Board and JP1 header the SDK did not recognize a device being present and no program/data was sent to the PCB.  I think this may be because the voltage output by the TAG board is 1.8 Volts and may not have been high enough to drive the voltage regulator in our circuit (pure speculation on my part).  Anyway the 3.3 V USB cable seems to be able to communicate with the PCB and yes, I have a reset button which I use to pull the Reset Pin on the BCM20736s module to ground... and it does seem to function correctly.  I know this because if I try to program a second time without pressing my reset button it will not recognize the device.  The power source with the USB cable is coming from the laptop.  I have not put a scope on it during the download process because I did not suspect any dips.  I can try that if you think it worth while.  According to our schematic the WP line (P0 or P1, I forget which at the moment) is pulled high permanently through a 10k resistor.  I believe P0 or P1 on the BCM20736S is connected to the memory chip on the module.  Is that correct?  The cable I have does not really mate with the TAG board so I don't see how I could test it with a known good TAG board.  Anyway in theory I should be able to program directly through the USB-UART cable without the TAG.  To test my cable with the TAG board I'd have to remove and re-engineer the other end of the cable so it would plug into the TAG board... or maybe I could wire it to JP1 and turn all the dip switches on SW4 to ON....  that might be interesting to try.  Looking for anything at all to try.  I don't know any details about how our PCB was assembled.  THe hardware guys took care of that.  Is there anything they should be careful of when assembling and stuffing the board?  I believe it was farmed out to a professional PCB assembly outfit, so have no reason to question the workmanship, except to say that Murphy's law has not been repealed yet.    

0 Likes
Reply
Anonymous
Not applicable

Have you tried pulling up SCL high(attach wire from SCL to 3.3V) previous to launching the recover process?

After SCL is pulled high you press the reset button. You pull SCL high because it disables the internet EPROM from being read since it kills the clock signal on I2C. After you hit the reset button release SCL (remove the wire) and then launch the recovery process. It's very important these steps are followed in that order.

(NOTE: For some reason the recovery process has worked for me several times when I was unable to program the chip. However, the SDK says when it finishes it failed but it actually worked.)

Anonymous
Not applicable

Don't you mean 'short SDA to ground' and then try to program?  See my thread linked earlier here.  I was able to recover several boards using the process outlined by .

At this point I would start cutting traces to isolate the SIP and scoping signals to see what's going on.  Without that you're just wasting time guessing.  The most likely culprit IMO is your PCB. Don't assume *anything* works correctly until you scope it.  Break the problem down into small parts.  Match up the log files between your PCB and a TAG board with the same FW.  See if you can spot any discrepancies.

My gut feeling is that you are dealing with a voltage mismatch (3.3 vs 1.8) on signal lines somehow.

0 Likes
Reply
Anonymous
Not applicable

Thanks Jose.  I think we had a 1.8 volt problem when programming with the TAG board as the middleman.  Since I am using a 3.3V FTDI USB to UART cable now instead of the Tag board, the voltage looks fine and we are getting data/program into the Sip module.  The problem seems to be writing the program to the internal EEPROM where we get a CRC error.  I can imagine that this might be due to our external EEPROM being on the same I2C bus as the internal EEPROM used to store the program.  The board is layered and rather small, about 1 inch square, so it's hard to find traces to cut and places to probe.  I did have a scope on the UART_RX and UART_TX on the download and it looks clean.  This is what the TX and RX lines look like during download.  At this point we have some FAE help on the line and I'll repost when we have a plan.  I think the next thing is to pull the external memory chip off the board.

Programming BCM20736S.jpg

0 Likes
Reply
Anonymous
Not applicable

No probe points?  Have your hardware guys taken out back and shot.

Timing-wise your serial data looks like it should but the delta-v's are different  2.4 vs 2.  It's just a possible vector that could cause the CRC to fail.  We have a mixed voltage board and we had issues with the serial lines -- HW guys didn't realize that I needed them for programming and hilarity ensued.

Anonymous
Not applicable

No firing squad until after they fix this thing!  Then maybe a reprieve if it's done in time for Christmas.  I think I see some test points on the board (looking with a magnifying glass), but they are not shown on my copy of the schematic for some reason.  Maybe they were added during layout.  I'll have to ask the hardware team what they connect to.

Looking at the scope again, it looks like 2.0 volts on the TX line and 2.8 volts on the RX line.  2.0 is below the legal limit for 3.3v CMOS logic (which I think is what my cable is)... so if the TX line contains the CRC data going back to the SDK that could explain a CRC failure... or is the CRC check done in the chip by the minidriver?

I gave up on programming with the TAG board because the logic levels output were only 1.8 volts.

If the TX signals are too low perhaps we could boost them by increasing the voltage supplied to the module (currently 2.2V).

0 Likes
Reply