cancel
Showing results for 
Search instead for 
Did you mean: 

Smart Bluetooth

Anonymous
Not applicable

I'm trying to program my application into 20732S on my board. But it fails.

I follow the command line procedure on below blog.

Programming the 20732S MODULE USING 2073xTAG Board

ChipLoad.exe looks successful to download minidriver.

But after chip erased, it's stopped.

Please refer attached cygwin.txt and logto.txt.

I'm using a simple board with 20732S referring SPIL schematic.

VBAT, GND, TXD and RXD are connects to TTL-232R-3V3.

Any advice please?

0 Likes
1 Solution
ArvindS_76
Employee

Assuming your device is connected to COM8 (IDE says COM11), the command line parameters to chipload.exe look right (you can keep the -NODLMINIDRIVER in there, just in case the chip is in recovery mode). I am still a bit surprised by the repeating 0x58 generic error code the minidriver is returning to chipload. Which SDK is the chipload.exe and the minidrive from? Can you try using the same from SDK 2.0.1? They will work with 20732S as long as the .hex file passed in as the parameter for -CONFIG was built with SDK 1.x.

View solution in original post

22 Replies
Anonymous
Not applicable

Hello dmiya,

What directory is your output.hex located?

JT

0 Likes
ArvindS_76
Employee

Is the EEPROM write protect pin connected to P1? It looks like the first write failed, and this is generally because the EEPROM NACK'ed the write because WP is asserted. Could you also post a picture of the EEPROM transaction when this first write is attempted?

0 Likes
Anonymous
Not applicable

Thank you for your comment.

I use 20732S module. So I think EEPROM write protect pin should be connected to P1 internallly.

When I saw I2C bus by the oscilloscipe, EEPROM issued ACK after slave address and write command (0xa0).

Then 20732 wrote many 0x00.

0 Likes
Anonymous
Not applicable

output.hex is located in same directory with ChipLoad.exe.

0 Likes
MichaelF_56
Moderator
Moderator

"I use 20732S module. So I think EEPROM write protect pin should be connected to P1 internallly."

Correct.

EEPROM-WP.png

0 Likes
Anonymous
Not applicable

Could you tell me what I need to correct?

0 Likes
ArvindS_76
Employee

Do you have a 10K pull-up on P1?

0 Likes
Anonymous
Not applicable

Is it nessesary for programming?

0 Likes
ShawnA_01
Employee

Hi dmiya,

Since Pin 25 is an input on powerup, its logic state is indeterminate unless biased one way or the other.

When Pin 25 is asserted low, the on-board EEPROM cannot be written, when asserted high it can be written.   If you want to be able to write to the EEPROM, you must assert this pin high.

Your text from 5/28 @ 8:12pm states you pulled it to ground.  This is the opposite of what you want to do.

There may be something else going on that's preventing the programming, but please assert it high and try again.

0 Likes
Anonymous
Not applicable

Hi santol,

I changed pin 25 to 10kohm pull-up. But it doesn't work.

Please help me.

0 Likes
Anonymous
Not applicable

I still can not program 20732S.

Is there any other way to program it?

In case, I tied WP(P1) to GND. But it didn't affect the result.

After sending the first 16 bytes in output.hex, the log says 0x58 as received byte from HW.

What does it mean?

0 Likes
ArvindS_76
Employee

0x58 is a generic error code that indicates something went wrong during the download. Looking at the log, it appears that the error occurred when the chipload tried to write the first few bytes to the EEPROM. Is there any other device on the I2C bus? Can you get a logic analyzer trace of the I2C transaction when the write is attempted? And also a portmon log of the uart transaction would be helpful.

0 Likes
Anonymous
Not applicable

Thank you for your help.

I don't connect anything on I2C.

I put 20732S on a breadboard and connect following 5 wires.

Pin3, 7, 18 and 19 are connected to TTL-232R-3V3 directly.

Pin25 is connected to 3 with 10kohm to pull it up.

I tried several boards but the results are all failed.

When I checked I2C bus by an oscilloscope, it wrote 32kB 0x00.

And it read address 0x00 (read was successful), then stopped suddenly.

After that there was no communication on I2C bus.

Could I have any advice on this?

0 Likes
Anonymous
Not applicable

Hello dmiya,

Are you still struggling with the programming of your device?

You mention the "TTL-232R-3V3" - Is this the FTDI cable you are using?

Please let us know if you are still struggling.

Thanks

JT

0 Likes
Anonymous
Not applicable

It's still an issue.

As I told before, I could program it by WICED SMART IDE.

But command line procedure doesn't work.

0 Likes
Anonymous
Not applicable

Hello dmiya,

I found an error on my chipload.exe command:

You need to change the minidriver parameter in Section 6.1 - Then it should work:

 

b.  Example Below: ./chipload.exe –BLUETOOLMODE –BAUDRATE 11520nfc –PORT COM16 –MINIDRIVER uart_64_byte_writes.hex –CONFIG output.hex –NODLMINIDRIVER –BTP 20732_TAG_EEPROM.btp

 

to:

 

  b.  Example Below: ./chipload.exe –BLUETOOLMODE –BAUDRATE 11520nfc –PORT COM16 –MINIDRIVER uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex –CONFIG output.hex –NODLMINIDRIVER –BTP 20732_TAG_EEPROM.btp

I hope this helps.

Thanks

JT

0 Likes
Anonymous
Not applicable

Hello JT,

Where can I get uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex?

Regards,

0 Likes
ArvindS_76
Employee

See <SDK>/Platforms/BCM92073*TAG_Q32/uart_*.hex

0 Likes
Anonymous
Not applicable

I found it and tried it. But the result wasn't changed.

0 Likes
ArvindS_76
Employee

Since you are able to download successfully with the SDK, enable verbose output in when building and downloading the app and compare the way the IDE invokes chipload.exe with how you invoke it. To enable verbose output, edit the build command (in the Make Target window) and add VERBOSE=1. Then clean, build and download the app. Scroll down towards the end of the console output to where it invokes chipload.exe

0 Likes
Anonymous
Not applicable

IDE outputs below log:

Tools\ChipLoad\Win32\chipload.exe -BLUETOOLMODE -PORT COM11 -BAUDRATE 115200 -MINIDRIVER Platforms/BCM920732TAG_Q32/uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex -BTP Platforms/BCM920732TAG_Q32/20732_EEPROM.btp -CONFIG build/sample115-BCM920732TAG_Q32-rom-ram-Wiced-release/sample115-BCM920732TAG_Q32-rom-ram-Wiced-release.hex > build/sample115-BCM920732TAG_Q32-rom-ram-Wiced-release/download.log

I used following command before.

./ChipLoad.exe -BLUETOOLMODE -BAUDRATE 115200nfc -PORT COM8 -MINIDRIVER uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex -CONFIG ./output.hex -BTP ./20732_TAG32_EEPROM.btp -NODLMINIDRIVER -LOGTO ./log.txt

Then I changed command but it still failed.

./ChipLoad.exe -BLUETOOLMODE -BAUDRATE 115200 -PORT COM8 -MINIDRIVER uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex -CONFIG ./output.hex -BTP ./20732_EEPROM.btp -LOGTO ./log.txt

Can I have your advice?

0 Likes
ArvindS_76
Employee

Assuming your device is connected to COM8 (IDE says COM11), the command line parameters to chipload.exe look right (you can keep the -NODLMINIDRIVER in there, just in case the chip is in recovery mode). I am still a bit surprised by the repeating 0x58 generic error code the minidriver is returning to chipload. Which SDK is the chipload.exe and the minidrive from? Can you try using the same from SDK 2.0.1? They will work with 20732S as long as the .hex file passed in as the parameter for -CONFIG was built with SDK 1.x.

View solution in original post