- Thu Feb 24, 2011 11:17 pm
#121213
Question: Are there any known conflicts with using I2C communications on the LPC2148 in combination with the SparkFun USB Bootloader?
Background:
I am trying to hack away at the Logomatic v2 (based on LPC2148) to get it to log data from I2C devices such as the SparkFun 9DOF Stick IMU.
I have modified a variety of "found" software for I2C drivers in other LPC family chips, using lots and lots of advice directly from the LPC2148 User Manual.
I have gotten code that successfully calls my "I2C Master Write" function, and the communication successfully lands in my I2C Interrupt Service Routine. I have verified that a complete transaction takes place, by blinking the LED for the I2STAT code on each entry to the ISR:
Issue Start
<enter ISR with I2STAT value 0x08, meaning "start" has been sent>
Load and send Slave Address + Write Bit.
Receive ACK
<enter ISR with I2STAT value 0x18, meaning "slave address + write sent, acknowledge received">
Load and Send data byte 1 (in my case a register address on the slave)
Receive ACK
<enter ISR with I2STAT value 0x28, meaning "data written, acknowledge received">
Load and Send data byte 2 (value for the register)
Receive ACK
<enter ISR with I2STAT value 0x28, meaning "data written, acknowledge received">
Send Stop Bit
HOWEVER, immediately upon the end of the I2CISR in this final state, the entire microcontroller RESETS and starts from the beginning of my main program. This happens with both I2C ports. If I blink the value from the reset interrupt identification register "RSIR," it reports that the reset was from a Power Down, but from looking at an oscilloscope, it does not appear that the voltage ever drops, so this may be an old value in that register, e.g. the microcontroller may not know that it reset.
So, again the question: is there any known conflict between I2C and the SparkFun USB Bootloader for ARM?
Or, is there any other obvious reason that returning from a completed I2C transfer would cause the microcontroller to reset?
Or could this be a compiler bug? (I'm running the stock version of WinARM 2006, as referenced in the Bootloader tutorial)
Any advice would be helpful!
Thanks,
-Peter
Background:
I am trying to hack away at the Logomatic v2 (based on LPC2148) to get it to log data from I2C devices such as the SparkFun 9DOF Stick IMU.
I have modified a variety of "found" software for I2C drivers in other LPC family chips, using lots and lots of advice directly from the LPC2148 User Manual.
I have gotten code that successfully calls my "I2C Master Write" function, and the communication successfully lands in my I2C Interrupt Service Routine. I have verified that a complete transaction takes place, by blinking the LED for the I2STAT code on each entry to the ISR:
Issue Start
<enter ISR with I2STAT value 0x08, meaning "start" has been sent>
Load and send Slave Address + Write Bit.
Receive ACK
<enter ISR with I2STAT value 0x18, meaning "slave address + write sent, acknowledge received">
Load and Send data byte 1 (in my case a register address on the slave)
Receive ACK
<enter ISR with I2STAT value 0x28, meaning "data written, acknowledge received">
Load and Send data byte 2 (value for the register)
Receive ACK
<enter ISR with I2STAT value 0x28, meaning "data written, acknowledge received">
Send Stop Bit
HOWEVER, immediately upon the end of the I2CISR in this final state, the entire microcontroller RESETS and starts from the beginning of my main program. This happens with both I2C ports. If I blink the value from the reset interrupt identification register "RSIR," it reports that the reset was from a Power Down, but from looking at an oscilloscope, it does not appear that the voltage ever drops, so this may be an old value in that register, e.g. the microcontroller may not know that it reset.
So, again the question: is there any known conflict between I2C and the SparkFun USB Bootloader for ARM?
Or, is there any other obvious reason that returning from a completed I2C transfer would cause the microcontroller to reset?
Or could this be a compiler bug? (I'm running the stock version of WinARM 2006, as referenced in the Bootloader tutorial)
Any advice would be helpful!
Thanks,
-Peter