Unable to write to the port

Hi,

I ran into this code of yours just as I bought a nRF24LE1 breakout board and a Bus Pirate v3, and decided to give it a go. However, when I try to upload a simple program to the controller, this is the output I receive: $ sudo ./nrfprog test1.hex Opening the Bus Pirate UART Setting the Bus Pirate to Binary Mode Configuring SPI mode Waiting to set up the XProtoLab Backing up the info page Writing test1.hex to the device Unable to write to the port!

Could you please help me with why it is not possible to write to the port?

Somewhere I read that the LE1 is write protected until you erase the entire flash memory (including the infopage), however I am not sure if this is true.

Also, the first time I ran nrfprog, I ran it with a hex file and not parameter-less to backup the infopage. Not sure if this could have caused any damage...

Thank you Ivan.

On 07/15/2012 07:08 AM, isovic wrote:

Hi,

I ran into this code of yours just as I bought a nRF24LE1 breakout board and a Bus Pirate v3, and decided to give it a go. However, when I try to upload a simple program to the controller, this is the output I receive: $ sudo ./nrfprog test1.hex Opening the Bus Pirate UART Setting the Bus Pirate to Binary Mode Configuring SPI mode Waiting to set up the XProtoLab Backing up the info page Writing test1.hex to the device Unable to write to the port!

Could you please help me with why it is not possible to write to the port?

To be honest, I'm not sure exactly why, but let's check a few things. First, make sure that the Bus Pirate is actually coming up as /dev/ttyUSB0. I hard coded that into the program, and it might not be true on your system.

Next, make sure that you don't have any terminal programs open and using the Bus Pirate. If you do, they will read from the serial port before the programmer can, and you'll get weird errors like this.

Finally, make sure that your Bus Pirate is at the main menu (try resetting it first). I did try to make sure that the Bus Pirate was reset, but it can get stuck in the binary mode some times.

Somewhere I read that the LE1 is write protected until you erase the entire flash memory (including the infopage), however I am not sure if this is true. I do not think this is true. You should not have to erase the info page, at least in my experience.

Also, the first time I ran nrfprog, I ran it with a hex file and not parameter-less to backup the infopage. Not sure if this could have caused any damage... The info page should have gotten backed up anyway, but you can check the info_page.dat file that's generated to make sure that the data is okay.

I hope this helps, -Joe

On Sun, Jul 15, 2012 at 3:13 PM, Joseph Jezak < reply@reply.github.com

wrote:

On 07/15/2012 07:08 AM, isovic wrote:

Hi,

I ran into this code of yours just as I bought a nRF24LE1 breakout board and a Bus Pirate v3, and decided to give it a go. However, when I try to upload a simple program to the controller, this is the output I receive: $ sudo ./nrfprog test1.hex Opening the Bus Pirate UART Setting the Bus Pirate to Binary Mode Configuring SPI mode Waiting to set up the XProtoLab Backing up the info page Writing test1.hex to the device Unable to write to the port!

Could you please help me with why it is not possible to write to the port?

To be honest, I'm not sure exactly why, but let's check a few things. First, make sure that the Bus Pirate is actually coming up as /dev/ttyUSB0. I hard coded that into the program, and it might not be true on your system.

Next, make sure that you don't have any terminal programs open and using the Bus Pirate. If you do, they will read from the serial port before the programmer can, and you'll get weird errors like this.

Finally, make sure that your Bus Pirate is at the main menu (try resetting it first). I did try to make sure that the Bus Pirate was reset, but it can get stuck in the binary mode some times.

Thank you for the advice, prior to posting here I have checked on which /dev/ttyUSBx port the Bus Pirate was, and even created a symbolic link, as explained on ArchLinux Wiki (https://wiki.archlinux.org/index.php/Bus_pirate). I have also looked at your code for a bit as I assumed that you hardcoded the port, so I changed it and recompiled, however, since my Bus Pirate has always shown up on ttyUSB0, either versions resulted the same.

Yeah, if the program is terminated before the connection to Bus Pirate is closed (i.e. the error that I have posted here), Bus Pirate hangs in the binary mode and needs to be unplugged.

I think that we can rule this case out.

Somewhere I read that the LE1 is write protected until you erase the entire flash memory (including the infopage), however I am not sure if this is true. I do not think this is true. You should not have to erase the info page, at least in my experience.

So, when you program your nRF24LE1, you simply plug it into the Bus Pirate, and run your tool, and it works, no extra steps?

Also, the first time I ran nrfprog, I ran it with a hex file and not parameter-less to backup the infopage. Not sure if this could have caused any damage...

The info page should have gotten backed up anyway, but you can check the

info_page.dat file that's generated to make sure that the data is okay.

Actually, now that I have inspected the info_page.dat file with a hex editor, it seems to be fine, but can you please confirm it just in case? First 32 bytes contain some data, the remaining are just 0xFF: 5A 5A 43 31 43 36 30 36 04 27 14 24 69 8E FA 5D 26 B1 52 11 0C FF FF FF FF 82 FF FF FF FF 00 00

Thank you for the suggestion!

I hope this helps, -Joe

It helped, at least to calm me down that I didn't brick my new nRF's :D

Do you know of any other tools/tutorials that work with nRF24LE1 and Bus Pirate?

Thank you so much for your help and your time! Ivan

On 07/15/2012 10:24 AM, isovic wrote:

On Sun, Jul 15, 2012 at 3:13 PM, Joseph Jezak < reply@reply.github.com

wrote: On 07/15/2012 07:08 AM, isovic wrote:

Hi,

I ran into this code of yours just as I bought a nRF24LE1 breakout board and a Bus Pirate v3, and decided to give it a go. However, when I try to upload a simple program to the controller, this is the output I receive: $ sudo ./nrfprog test1.hex Opening the Bus Pirate UART Setting the Bus Pirate to Binary Mode Configuring SPI mode Waiting to set up the XProtoLab Backing up the info page Writing test1.hex to the device Unable to write to the port!

Could you please help me with why it is not possible to write to the port?

To be honest, I'm not sure exactly why, but let's check a few things. First, make sure that the Bus Pirate is actually coming up as /dev/ttyUSB0. I hard coded that into the program, and it might not be true on your system.

Next, make sure that you don't have any terminal programs open and using the Bus Pirate. If you do, they will read from the serial port before the programmer can, and you'll get weird errors like this.

Finally, make sure that your Bus Pirate is at the main menu (try resetting it first). I did try to make sure that the Bus Pirate was reset, but it can get stuck in the binary mode some times.

Thank you for the advice, prior to posting here I have checked on which /dev/ttyUSBx port the Bus Pirate was, and even created a symbolic link, as explained on ArchLinux Wiki (https://wiki.archlinux.org/index.php/Bus_pirate). I have also looked at your code for a bit as I assumed that you hardcoded the port, so I changed it and recompiled, however, since my Bus Pirate has always shown up on ttyUSB0, either versions resulted the same.

Yeah, if the program is terminated before the connection to Bus Pirate is closed (i.e. the error that I have posted here), Bus Pirate hangs in the binary mode and needs to be unplugged.

I think that we can rule this case out.

Yeah, that rules out the first and last one, but again, make sure that nothing else is reading from the port as well!

Okay, well we have a few other things to test. First, what version of the Bus Pirate software are you using? It may be that you're using an older/newer version than I used and the binary interface changed.

Also, can you try defining "DEBUG_PRINT" (pass -DDEBUG_PRINT in CFLAGS when compiling), perhaps we can identify where exactly it's getting tripped up.

Somewhere I read that the LE1 is write protected until you erase the entire flash memory (including the infopage), however I am not sure if this is true. I do not think this is true. You should not have to erase the info page, at least in my experience.

So, when you program your nRF24LE1, you simply plug it into the Bus Pirate, and run your tool, and it works, no extra steps?

Yes, that's what happens for me. For what it's worth, I got my nRF24LE1 breakouts from MDFLY and the first one that I got was bad. I could read/write to the EEPROM, but the chip itself would never show any signs of life. The replacement (which they sent for free after two weeks of my debugging and pulling my hair out) worked great!

Also, the first time I ran nrfprog, I ran it with a hex file and not parameter-less to backup the infopage. Not sure if this could have caused any damage... The info page should have gotten backed up anyway, but you can check the info_page.dat file that's generated to make sure that the data is okay.

Actually, now that I have inspected the info_page.dat file with a hex editor, it seems to be fine, but can you please confirm it just in case? First 32 bytes contain some data, the remaining are just 0xFF: 5A 5A 43 31 43 36 30 36 04 27 14 24 69 8E FA 5D 26 B1 52 11 0C FF FF FF FF 82 FF FF FF FF 00 00

Thank you for the suggestion!

Yeah, that looks reasonable. Unfortunately, Nordic doesn't really tell us what that information means, so I can't say for sure, but it has a similar structure to the good info pages I've read from devices.

I hope this helps, -Joe

It helped, at least to calm me down that I didn't brick my new nRF's :D

Do you know of any other tools/tutorials that work with nRF24LE1 and Bus Pirate? No, I don't. I wasn't able to find any way to program the nRF24LE1 without spending money (and using Windows, and that wasn't happening!) so I wrote this program using the data sheet as a guide. If you have an SPI based device (like an arduino), you could probably rewrite my code to work for that as well.

Thank you so much for your help and your time! Ivan

No worries! -Joe

On Sun, Jul 15, 2012 at 5:37 PM, Joseph Jezak < reply@reply.github.com

wrote:

On 07/15/2012 10:24 AM, isovic wrote:

On Sun, Jul 15, 2012 at 3:13 PM, Joseph Jezak < reply@reply.github.com

wrote: On 07/15/2012 07:08 AM, isovic wrote:

Hi,

I ran into this code of yours just as I bought a nRF24LE1 breakout board and a Bus Pirate v3, and decided to give it a go. However, when I try to upload a simple program to the controller, this is the output I receive: $ sudo ./nrfprog test1.hex Opening the Bus Pirate UART Setting the Bus Pirate to Binary Mode Configuring SPI mode Waiting to set up the XProtoLab Backing up the info page Writing test1.hex to the device Unable to write to the port!

Could you please help me with why it is not possible to write to the port?

To be honest, I'm not sure exactly why, but let's check a few things. First, make sure that the Bus Pirate is actually coming up as /dev/ttyUSB0. I hard coded that into the program, and it might not be true on your system.

Next, make sure that you don't have any terminal programs open and using the Bus Pirate. If you do, they will read from the serial port before the programmer can, and you'll get weird errors like this.

Finally, make sure that your Bus Pirate is at the main menu (try resetting it first). I did try to make sure that the Bus Pirate was reset, but it can get stuck in the binary mode some times.

Thank you for the advice, prior to posting here I have checked on which /dev/ttyUSBx port the Bus Pirate was, and even created a symbolic link, as explained on ArchLinux Wiki ( https://wiki.archlinux.org/index.php/Bus_pirate). I have also looked at your code for a bit as I assumed that you hardcoded the port, so I changed it and recompiled, however, since my Bus Pirate has always shown up on ttyUSB0, either versions resulted the same.

Yeah, if the program is terminated before the connection to Bus Pirate is closed (i.e. the error that I have posted here), Bus Pirate hangs in the binary mode and needs to be unplugged.

I think that we can rule this case out.

Yeah, that rules out the first and last one, but again, make sure that nothing else is reading from the port as well!

Okay, well we have a few other things to test. First, what version of the Bus Pirate software are you using? It may be that you're using an older/newer version than I used and the binary interface changed.

Also, can you try defining "DEBUG_PRINT" (pass -DDEBUG_PRINT in CFLAGS when compiling), perhaps we can identify where exactly it's getting tripped up.

The version-compatibility issue idea has ran across my mind a few moments before receiving your message! My Bus Pirate is a v3.6 (printed on the PCB on the back), however, I am not sure how to check the firmware version? I just bought it a week or two ago, so I presume the firmware should be an recent upgrade. When I connect to the Bus Pirate through a hyper terminal, the command list differs from the one listed in the Bus Pirate 101 Tutorial...

The debug part - actually, I have done that yesterday :) I ran it again today, the output is a little big, so I'll try to attach it in this email reply and hope it appears on the github forum.

Somewhere I read that the LE1 is write protected until you erase the entire flash memory (including the infopage), however I am not sure if this is true. I do not think this is true. You should not have to erase the info page, at least in my experience.

So, when you program your nRF24LE1, you simply plug it into the Bus Pirate, and run your tool, and it works, no extra steps?

Yes, that's what happens for me. For what it's worth, I got my nRF24LE1 breakouts from MDFLY and the first one that I got was bad. I could read/write to the EEPROM, but the chip itself would never show any signs of life. The replacement (which they sent for free after two weeks of my debugging and pulling my hair out) worked great!

Huh, I completely understand... I waited for mine for 2 weeks, and now when it finally came, I cannot seem to get it to work...

Also, the first time I ran nrfprog, I ran it with a hex file and not parameter-less to backup the infopage. Not sure if this could have caused any damage... The info page should have gotten backed up anyway, but you can check the info_page.dat file that's generated to make sure that the data is okay.

Actually, now that I have inspected the info_page.dat file with a hex editor, it seems to be fine, but can you please confirm it just in case? First 32 bytes contain some data, the remaining are just 0xFF: 5A 5A 43 31 43 36 30 36 04 27 14 24 69 8E FA 5D 26 B1 52 11 0C FF FF FF FF 82 FF FF FF FF 00 00

Thank you for the suggestion!

Yeah, that looks reasonable. Unfortunately, Nordic doesn't really tell us what that information means, so I can't say for sure, but it has a similar structure to the good info pages I've read from devices.

Thanks!

I hope this helps, -Joe

It helped, at least to calm me down that I didn't brick my new nRF's :D

Do you know of any other tools/tutorials that work with nRF24LE1 and Bus Pirate? No, I don't. I wasn't able to find any way to program the nRF24LE1 without spending money (and using Windows, and that wasn't happening!) so I wrote this program using the data sheet as a guide. If you have an SPI based device (like an arduino), you could probably rewrite my code to work for that as well.

That's exactly what I'm trying to do, since spending $500 for nRF Starter Kit seems a bit too much... So imagine how happy I felt when I found your project :) And it's so close to working...

I have started porting your code to Windows, as the code isn't big, and so I don't have to reboot my computer to switch between tools. Maybe I'll even give it a little user interface when I get some time.

Will report the progress on the port when it's finished.

Thanks again! main() [nrfprog.c:585] here Opening the Bus Pirate UART ser_open() [nrfprog.c:27] here Setting the Bus Pirate to Binary Mode ser_bp_bin() [nrfprog.c:110] here ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: -1 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x00 sz: 5 0x42 B 0x42 B 0x49 I 0x4F O 0x31 1 Configuring SPI mode ser_bp_spi_cfg() [nrfprog.c:197] here ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x01 ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x60 check_resp() [nrfprog.c:163] here Response: 0x1 () ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x8A check_resp() [nrfprog.c:163] here Response: 0x1 () ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x4A check_resp() [nrfprog.c:163] here Response: 0x1 () ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x48 check_resp() [nrfprog.c:163] here Response: 0x1 () ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x4A check_resp() [nrfprog.c:163] here Response: 0x1 () Waiting to set up the XProtoLab Backing up the info page read_hex() [nrfprog.c:479] here spi_cmd() [nrfprog.c:325] here ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x04 ser_write() [nrfprog.c:75] here 0x00 0x02 ser_write() [nrfprog.c:75] here 0x00 0x00 ser_write() [nrfprog.c:75] here 0x01 0x08 check_resp() [nrfprog.c:163] here Response: 0x1 () spi_read() [nrfprog.c:346] here ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x04 ser_write() [nrfprog.c:75] here 0x00 0x03 ser_write() [nrfprog.c:75] here 0x02 0x00 ser_write() [nrfprog.c:75] here 0x03 ser_write() [nrfprog.c:75] here 0x00 0x00 check_resp() [nrfprog.c:163] here Response: 0x1 () READ 512 bytes 0x5A 0x5A 0x43 0x31 0x43 0x36 0x30 0x36 0x04 0x27 0x14 0x24 0x69 0x8E 0xFA 0x5D 0x26 0xB1 0x52 0x11 0x0C 0xFF 0xFF 0xFF 0xFF 0x82 0xFF 0xFF 0xFF 0xFF 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF Writing test1.hex to the device write_hex() [nrfprog.c:530] here hf_read() [nrfprog.c:242] here spi_cmd() [nrfprog.c:325] here ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x04 ser_write() [nrfprog.c:75] here 0x00 0x02 ser_write() [nrfprog.c:75] here 0x00 0x00 ser_write() [nrfprog.c:75] here 0x01 0x00 check_resp() [nrfprog.c:163] here Response: 0x1 () spi_cmd() [nrfprog.c:325] here ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x04 ser_write() [nrfprog.c:75] here 0x00 0x01 ser_write() [nrfprog.c:75] here 0x00 0x00 ser_write() [nrfprog.c:75] here 0x06 check_resp() [nrfprog.c:163] here Response: 0x1 () spi_cmd() [nrfprog.c:325] here ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x04 ser_write() [nrfprog.c:75] here 0x00 0x02 ser_write() [nrfprog.c:75] here 0x00 0x00 ser_write() [nrfprog.c:75] here 0x52 0x00 check_resp() [nrfprog.c:163] here Response: 0x1 () spi_wait() [nrfprog.c:395] here ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x04 ser_write() [nrfprog.c:75] here 0x00 0x01 ser_write() [nrfprog.c:75] here 0x00 0x01 ser_write() [nrfprog.c:75] here 0x05 check_resp() [nrfprog.c:163] here Response: 0x1 () spi_write() [nrfprog.c:441] here spi_cmd() [nrfprog.c:325] here ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x04 ser_write() [nrfprog.c:75] here 0x00 0x01 ser_write() [nrfprog.c:75] here 0x00 0x00 ser_write() [nrfprog.c:75] here 0x06 check_resp() [nrfprog.c:163] here Response: 0x1 () ser_cmd() [nrfprog.c:99] here ser_write() [nrfprog.c:75] here 0x04 ser_write() [nrfprog.c:75] here 0x02 0x03 ser_write() [nrfprog.c:75] here 0x00 0x00 ser_write() [nrfprog.c:75] here 0x02 ser_write() [nrfprog.c:75] here 0x00 0x00 ser_write() [nrfprog.c:75] here 0x02 0x00 0x13 0x32 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x02 0x00 0x83 0x12 0x00 0xAC 0x80 0xFE 0x75 0x81 0x09 0x12 0x00 0xBF 0xE5 0x82 0x60 0x03 0x02 0x00 0x0E 0x79 0x00 0xE9 0x44 0x00 0x60 0x1B Unable to write to the port!

Btw. how do you connect your PROG pin? In my setup, I just connected it to 3V3, since the datasheet says that it only needs to be driven 1.5ms before the usage. Although, if this was the problem, then none of the SPI commands would have worked... :)

Ivan

On 07/15/2012 06:36 PM, isovic wrote:

Btw. how do you connect your PROG pin? In my setup, I just connected it to 3V3, since the datasheet says that it only needs to be driven 1.5ms before the usage. Although, if this was the problem, then none of the SPI commands would have worked... :)

Ivan

Reply to this email directly or view it on GitHub: https://github.com/JoseJX/nrfprog/issues/1#issuecomment-6995782

True! You need to connect the PROG pin to 3.3v and hold it there while programming. The reset should be hooked up to the AUX pin (important!) and the ground/vcc/SPI hooked up as specified by your chip's data sheet.

I've got the older v2go version of the Bus Pirate with a v5 firmware, 5.9 or 5.10, I don't remember.

That said, looking at your dumps, it really looks like most everything is working, but that when it goes to write the file to the EEPROM, it overflows the write buffer (which closes the device). Perhaps try inserting a pause between each byte written? Maybe your computer is a lot faster than mine! :)

-Joe

On Mon, Jul 16, 2012 at 3:15 AM, Joseph Jezak < reply@reply.github.com

wrote:

On 07/15/2012 06:36 PM, isovic wrote:

Btw. how do you connect your PROG pin? In my setup, I just connected it to 3V3, since the datasheet says that it only needs to be driven 1.5ms before the usage. Although, if this was the problem, then none of the SPI commands would have worked... :)

Ivan

Reply to this email directly or view it on GitHub: https://github.com/JoseJX/nrfprog/issues/1#issuecomment-6995782

True! You need to connect the PROG pin to 3.3v and hold it there while programming. The reset should be hooked up to the AUX pin (important!) and the ground/vcc/SPI hooked up as specified by your chip's data sheet.

I've got the older v2go version of the Bus Pirate with a v5 firmware, 5.9 or 5.10, I don't remember.

That said, looking at your dumps, it really looks like most everything is working, but that when it goes to write the file to the EEPROM, it overflows the write buffer (which closes the device). Perhaps try inserting a pause between each byte written? Maybe your computer is a lot faster than mine! :)

Great suggestion, thanks! :) I've put a small delay at the end of every byte in the ser_write function (i.e. usleep(10)), now it doesn't crash as before! However, when all memory pages have been sent, the memory read test fails... It seems that the memory never actually gets written... :/ I get errors for every memory address such as: Error at address: 0x00003FC7: 0x00 != 0xFF . (0xFF differs, depending on the .hex file that is being sent)

Do you maybe have a simple sample .hex file that you know for sure works with nRF24LE1, for instance just to turn-on a led on some port? I've written my code and compiled it with SDCC (don't have Keil), but a tested-out version might provide a better benchmark.

Your suggestions have been really helpful, thank you very much, again! :)

Ivan

On 07/16/2012 05:19 AM, isovic wrote:

On Mon, Jul 16, 2012 at 3:15 AM, Joseph Jezak < reply@reply.github.com

wrote: On 07/15/2012 06:36 PM, isovic wrote:

Btw. how do you connect your PROG pin? In my setup, I just connected it to 3V3, since the datasheet says that it only needs to be driven 1.5ms before the usage. Although, if this was the problem, then none of the SPI commands would have worked... :)

Ivan

Reply to this email directly or view it on GitHub: https://github.com/JoseJX/nrfprog/issues/1#issuecomment-6995782

True! You need to connect the PROG pin to 3.3v and hold it there while programming. The reset should be hooked up to the AUX pin (important!) and the ground/vcc/SPI hooked up as specified by your chip's data sheet.

I've got the older v2go version of the Bus Pirate with a v5 firmware, 5.9 or 5.10, I don't remember.

That said, looking at your dumps, it really looks like most everything is working, but that when it goes to write the file to the EEPROM, it overflows the write buffer (which closes the device). Perhaps try inserting a pause between each byte written? Maybe your computer is a lot faster than mine! :)

Great suggestion, thanks! :) I've put a small delay at the end of every byte in the ser_write function (i.e. usleep(10)), now it doesn't crash as before! However, when all memory pages have been sent, the memory read test fails... It seems that the memory never actually gets written... :/ I get errors for every memory address such as: Error at address: 0x00003FC7: 0x00 != 0xFF . (0xFF differs, depending on the .hex file that is being sent)

Do you maybe have a simple sample .hex file that you know for sure works with nRF24LE1, for instance just to turn-on a led on some port? I've written my code and compiled it with SDCC (don't have Keil), but a tested-out version might provide a better benchmark.

Your suggestions have been really helpful, thank you very much, again! :)

Ivan

Reply to this email directly or view it on GitHub: https://github.com/JoseJX/nrfprog/issues/1#issuecomment-7001667

I have a bit of simple LED blinker code (on P0.0, P0.1, P0.2) that I was testing with an RGB LED on my nRF24LE1 board. I put this up at http://dev.gentoo.org/~josejx/nrf24le1-blinker.tar which also contains the compiled .hex file. I haven't tried this recently as I haven't done any development on this board in a few months, but this should build and run fine in SDCC.

-Joe

It works!! Aside from putting the additional delay in the code, the problem was in the order of enabling the WREN bit. In the original code, WREN is enabled prior to erasing a page, but it seems that erasing a page resets the WREN bit. Changing the order of these two operations seems to fix the problem for me. Here is the copied part of the modified source code in the write_hex function:

    cmd_bytes[0] = NRF24_SPI_ERASE_PAGE;
    cmd_bytes[1] = pos / NRF24_BLOCK_SZ;
    spi_cmd(fd, cmd_bytes, 2, "Erase Page");

    // Check that we've completed the erase command
    cmd_bytes[0] = NRF24_SPI_RDSR;
    result = 0;
    spi_wait(fd, cmd_bytes, 1,  &result, 1, "Waiting for the erase to complete");

    // Set WREN to enable writing
    cmd_bytes[0] = NRF24_SPI_WREN;
    spi_cmd(fd, cmd_bytes, 1, "Enable Writing");

Joe, thank you so much for your input and help!!

Best regards, Ivan.

On 07/17/2012 07:21 AM, isovic wrote:

It works!! Aside from putting the additional delay in the code, the problem was in the order of enabling the WREN bit. In the original code, WREN is enabled prior to erasing a page, but it seems that erasing a page resets the WREN bit. Changing the order of these two operations seems to fix the problem for me. Here is the copied part of the modified source code in the write_hex function:
  cmd_bytes[0] = NRF24_SPI_ERASE_PAGE;
  cmd_bytes[1] = pos / NRF24_BLOCK_SZ;
  spi_cmd(fd, cmd_bytes, 2, "Erase Page");

  // Check that we've completed the erase command
  cmd_bytes[0] = NRF24_SPI_RDSR;
  result = 0;
  spi_wait(fd, cmd_bytes, 1,  &result, 1, "Waiting for the erase to complete");

  // Set WREN to enable writing
  cmd_bytes[0] = NRF24_SPI_WREN;
  spi_cmd(fd, cmd_bytes, 1, "Enable Writing");
Joe, thank you so much for your input and help!!

Best regards, Ivan.

Reply to this email directly or view it on GitHub: https://github.com/JoseJX/nrfprog/issues/1#issuecomment-7032545

Well, that's really weird! According to the manual, you need to set WREN before clearing a page, so logically, it shouldn't work at all with the WREN being enabled after the erase! :) Turning off the WREN bit after the erase is the expected behavior, so that's actually okay. It's possible that timing issues are again causing problems here. Can you try adding a delay after enabling the WREN bit in the original code? Perhaps what's happening here is that by putting the WREN at the end of the code block, it's staying enabled after the "erase", so when you go to erase the next block, it's already enabled?

I'll have to play with it a bit with my nRF24LE1 devices to see if I can reproduce this problem at all.

Anyway, I'm glad it works for you! -Joe

On Tue, Jul 17, 2012 at 4:45 PM, Joseph Jezak < reply@reply.github.com

wrote:

On 07/17/2012 07:21 AM, isovic wrote:
It works!! Aside from putting the additional delay in the code, the problem was in the order of enabling the WREN bit. In the original code, WREN is enabled prior to erasing a page, but it seems that erasing a page resets the WREN bit. Changing the order of these two operations seems to fix the problem for me. Here is the copied part of the modified source code in the write_hex function:
          cmd_bytes[0] = NRF24_SPI_ERASE_PAGE;
          cmd_bytes[1] = pos / NRF24_BLOCK_SZ;
          spi_cmd(fd, cmd_bytes, 2, "Erase Page");

          // Check that we've completed the erase command
          cmd_bytes[0] = NRF24_SPI_RDSR;
          result = 0;
          spi_wait(fd, cmd_bytes, 1,  &result, 1, "Waiting for the
erase to complete");
          // Set WREN to enable writing
          cmd_bytes[0] = NRF24_SPI_WREN;
          spi_cmd(fd, cmd_bytes, 1, "Enable Writing");
Joe, thank you so much for your input and help!!

Best regards, Ivan.

Reply to this email directly or view it on GitHub: https://github.com/JoseJX/nrfprog/issues/1#issuecomment-7032545

Well, that's really weird! According to the manual, you need to set WREN before clearing a page, so logically, it shouldn't work at all with the WREN being enabled after the erase! :) Turning off the WREN bit after the erase is the expected behavior, so that's actually okay. It's possible that timing issues are again causing problems here. Can you try adding a delay after enabling the WREN bit in the original code? Perhaps what's happening here is that by putting the WREN at the end of the code block, it's staying enabled after the "erase", so when you go to erase the next block, it's already enabled?
I'll have to play with it a bit with my nRF24LE1 devices to see if I can reproduce this problem at all.

Anyway, I'm glad it works for you! -Joe

Hi Joe,

I'm sorry for the late response, I was swamped for the past two days... This is a really interesting issue. Actually, putting the delays was the first thing that I've tried with the code, I've put them all around, everywhere where there's any communication with the serial port :) But it didn't work. It was thrilling to see the thing actually work, although, interesting enough, I tried to connect everything again yesterday, and it wouldn't flash the chip, again! The nRF is still programmed though, port is being activated periodically... At this point I'm stumped, but this is an interesting challenge for me and will continue trying to resolve it, especially now that I finally managed to obtain some 2.0mm headers and can make the whole setup a lot more practical. This weekend I'm going on a trip and will continue to work on this next week. Will post progress, if any should occur :)

Thank you for all your help! If you think of anything else, don't hesitate to write :)

Ivan

JoseJX / nrfprog

Unable to write to the port #1