Quantcast
Channel: Microcontrollers
Viewing all articles
Browse latest Browse all 221819

Forum Post: RE: EK-TM4C129EXL: Updating firmware using I2C with the ROM Bootloader - Hanging after successful COMMAND_GET_STATUS

$
0
0
[quote userid="467243" 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/5586220#5586220"]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). [/quote] That is correct. [quote userid="467243" 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/5586220#5586220"] 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][quote userid="467243" 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/5586220#5586220"] [/quote] I revised my original reply while you sent your response. In my revised reply, I mentioned that the master must still generate clocks for the slave to return the data. However, looking at your above waveform closely, it seems to me that the SCL is low. This can mean two things but I don't know which is which. The first possibility is that the master is not putting out the clocks or in the second case the slave is stretching the clock as means to hold the master in wait state per I2C protocol.

Viewing all articles
Browse latest Browse all 221819

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>