Hi Charles, thanks for the detailed response. Addressing your questions below: [quote userid="93620" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1456117/ek-tm4c129exl-updating-firmware-using-i2c-with-the-rom-bootloader---hanging-after-successful-command_get_status/5586093#5586093"] Checksum: 0x8C, Can you confirm if 0x8C is correct? [/quote] I believe the checksum is correct. The checksum is calculated using the following data: 0x24 + 0x00 + 0x02 + 0x20 + 0x3F + 0x07 + 0x00 + 0x00. This comes to 0x8C. [quote userid="93620" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1456117/ek-tm4c129exl-updating-firmware-using-i2c-with-the-rom-bootloader---hanging-after-successful-command_get_status/5586093#5586093"]Comparing to the working waveform, I see "R 0x42" -> "0x00" -> "0xCC", the non working waveform does not follow with the 0x00. I'm a bit confused with myself with this 0x00 the second byte. I believe this is supposed to come from the slave because master issues a I2C read command.[/quote] Yes, I agree the second (as well as third) byte is supposed to come from the slave. This is where things fail and I get no more response from the slave. To explain a bit more: My understanding of how the default bootloader works is when the master sends a valid command the bootloader will respond with an ACK. This ACK consists of two bytes (0x00 followed by 0xCC). If there is some issue the bootloader will respond with a NACK (0x33 instead of 0xCC). Of course to obtain the ACK or NACK the master must do a read. This is what is happening when you see the master send "R 0x42" - it's initiating the read of the ACK/NACK. And you're correct, the first sign of a problem is when the master sends the "R 0x42" and gets nothing back... And this is when everything fails and I no longer get any responses from the slave (i.e. the target). [quote userid="93620" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1456117/ek-tm4c129exl-updating-firmware-using-i2c-with-the-rom-bootloader---hanging-after-successful-command_get_status/5586093#5586093"] Can you issue a PING command to see if the slave is in bootloader mode or not?[/quote] Yes, I've added code so the very first thing the master does is issue a ping to make sure it can talk to the target's bootloader. The following images from my logic analyzer shows the ping command, the ACK, followed by a "get status" command, the ACK for it and then the successful status - all looks good. I had to break up the images a bit because it would be too long to all show vertically: I can actually continue on with this to show the issue I'm experiencing. So, after the ping, I send the "download" command. Here it is: Then I go to read the ACK for the "download" command and, just like in my example from my original post, I get no response from the bootloader. The SCL line is held low indefinitely: Looking at this closer, I originally thought the slave (the bootloader) was holding the clock line low but I'm not sure that's the case. I wonder if all the master needs to do is send more clock signals to get a response from the bootloader. I will investigate this. [quote userid="93620" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1456117/ek-tm4c129exl-updating-firmware-using-i2c-with-the-rom-bootloader---hanging-after-successful-command_get_status/5586093#5586093"] Can you refer to this serial bootloader app note. Not sure if you have reference this app note when you develop your serial programmer on the master I2C side. https://www.ti.com/lit/an/spma074a/spma074a.pdf [/quote] Thank you, I was not aware of this app note. I was using SPMU301E (TivaWare Bootloader User's Guide) and the TivaWare bootloader code to create my code. I will review SPMA074A as well. [quote userid="93620" url="~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1456117/ek-tm4c129exl-updating-firmware-using-i2c-with-the-rom-bootloader---hanging-after-successful-command_get_status/5586093#5586093"]Here I'm a bit confused here. Earlier you said the I2C slave hangs with the ACK response check. Here you seem to suggest the hang is due to GET_STATUS. There are two types of response: Type-1 (ACK or NAK response) and Type-2 (GET_STATUS). Which one is hanging?[/quote] Apologies for the confusion. To be clear, when I remove my GET_STATUS calls and leave in my ACK reads, everything works. The ping command works, the download command works, the many send data commands work as well as the reset command after finished with my send data commands and my target board is successfully updated with new firmware. Now, as shown above with my ping example, as soon as I add a GET_STATUS command the *ACK* on the *following* command will hang. Does that description make sense? ...I know, it's weird and I can't currently make sense of it.
↧