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.
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.
Gmelcher, I don't know what the address is on the external memory chip. I will investigate.
Thanks for the tip.
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
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 arvinds.
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.
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 ****"
****Download failed - Press the reset button on the device and retry ****
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. MiTo_1583836 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.
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.
1 of 1 people found this helpful
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.
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).
1 of 1 people found this helpful
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
1 of 1 people found this helpful
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.