- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello dmiya,
What directory is your output.hex located?
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
output.hex is located in same directory with ChipLoad.exe.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"I use 20732S module. So I think EEPROM write protect pin should be connected to P1 internallly."
Correct.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you tell me what I need to correct?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have a 10K pull-up on P1?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is it nessesary for programming?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi santol,
I changed pin 25 to 10kohm pull-up. But it doesn't work.
Please help me.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's still an issue.
As I told before, I could program it by WICED SMART IDE.
But command line procedure doesn't work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello JT,
Where can I get uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex?
Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
See <SDK>/Platforms/BCM92073*TAG_Q32/uart_*.hex
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I found it and tried it. But the result wasn't changed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.