Hi!
I have a 24CXX I2C EEPROM which needs a special software reset procedure that
involves sending a start condition directly followed by a stop condition. The
EEPROM is connected to the USCI of a MSP430F54xx and is the only device on
the
bus. Having read the respective chapter in the user manual I would say that
the
USCI isn't capable of sending the required sequence and that I have to
reset the
EEPROM by other means. I thought about powering the EEPROM up and down with a
port pin because this is much more simpler and safer than the software reset
procedure but this is not possible with the current revision of my hardware.
Another solution would be to bit bang the reset sequence but this is pretty
ugly, so I wonder if there is any trick to send the required sequence with
the
USCI.
Regards,
Markus
I2C with USCI: Stop condition directly after a start condition?
Started by ●December 16, 2009
Reply by ●December 17, 20092009-12-17
Your requirement sounds strange but feasible. What's the EEPROM model or
datasheet link?
In any case, bitbanging this software reset should be a piece of cake. Really, really easy. Do you know how to generate the "open colector output pin" behaviour with MSP? As in software I2C?
Regards,
Michael K.
--- In m..., Markus Schaub wrote:
>
> Hi!
>
> I have a 24CXX I2C EEPROM which needs a special software reset procedure that
> involves sending a start condition directly followed by a stop condition. The
> EEPROM is connected to the USCI of a MSP430F54xx and is the only device on the
> bus. Having read the respective chapter in the user manual I would say that the
> USCI isnt capable of sending the required sequence and that I have to reset the
> EEPROM by other means. I thought about powering the EEPROM up and down with a
> port pin because this is much more simpler and safer than the software reset
> procedure but this is not possible with the current revision of my hardware.
> Another solution would be to bit bang the reset sequence but this is pretty
> ugly, so I wonder if there is any trick to send the required sequence with the
> USCI.
>
> Regards,
> Markus
>
In any case, bitbanging this software reset should be a piece of cake. Really, really easy. Do you know how to generate the "open colector output pin" behaviour with MSP? As in software I2C?
Regards,
Michael K.
--- In m..., Markus Schaub wrote:
>
> Hi!
>
> I have a 24CXX I2C EEPROM which needs a special software reset procedure that
> involves sending a start condition directly followed by a stop condition. The
> EEPROM is connected to the USCI of a MSP430F54xx and is the only device on the
> bus. Having read the respective chapter in the user manual I would say that the
> USCI isnt capable of sending the required sequence and that I have to reset the
> EEPROM by other means. I thought about powering the EEPROM up and down with a
> port pin because this is much more simpler and safer than the software reset
> procedure but this is not possible with the current revision of my hardware.
> Another solution would be to bit bang the reset sequence but this is pretty
> ugly, so I wonder if there is any trick to send the required sequence with the
> USCI.
>
> Regards,
> Markus
>
Reply by ●December 18, 20092009-12-18
Michael schrieb:
>> I have a 24CXX I2C EEPROM which needs a special software reset procedure that
>> involves sending a start condition directly followed by a stop condition. The
>> EEPROM is connected to the USCI of a MSP430F54xx and is the only device on the
>> bus. Having read the respective chapter in the user manual I would say that the
>> USCI isn?t capable of sending the required sequence and that I have to reset the
>> EEPROM by other means. I thought about powering the EEPROM up and down with a
>> port pin because this is much more simpler and safer than the software reset
>> procedure but this is not possible with the current revision of my hardware.
>> Another solution would be to bit bang the reset sequence but this is pretty
>> ugly, so I wonder if there is any trick to send the required sequence with the
>> USCI.
> Your requirement sounds strange but feasible. What's the EEPROM model or
> datasheet link?
It is an AT24C04B, not a device which I would call very uncommon or
extraordinary. The datasheet says:
| 2-WIRE SOFTWARE RESET: After an interruption in protocol, power loss or system
| reset, 2-wire part can be reset by following these steps:
| (a) Create a start bit condition,
| (b) Clock 9 cycles,
| (c) Create another start bit followed by a stop bit condition as shown below.
| The device is ready for the next communication after the above steps have
| been completed.
> In any case, bitbanging this software reset should be a piece of cake. Really,
> really easy.
For sure, it's easy but I was hoping to get the job done by the USCI module
rather than writing delay loops (or waste a timer) in order to maintain the
correct timing.
> Do you know how to generate the "open colector output pin" behaviour with MSP?
> As in software I2C?
Sure, there's noting special about that.
Markus
>> I have a 24CXX I2C EEPROM which needs a special software reset procedure that
>> involves sending a start condition directly followed by a stop condition. The
>> EEPROM is connected to the USCI of a MSP430F54xx and is the only device on the
>> bus. Having read the respective chapter in the user manual I would say that the
>> USCI isn?t capable of sending the required sequence and that I have to reset the
>> EEPROM by other means. I thought about powering the EEPROM up and down with a
>> port pin because this is much more simpler and safer than the software reset
>> procedure but this is not possible with the current revision of my hardware.
>> Another solution would be to bit bang the reset sequence but this is pretty
>> ugly, so I wonder if there is any trick to send the required sequence with the
>> USCI.
> Your requirement sounds strange but feasible. What's the EEPROM model or
> datasheet link?
It is an AT24C04B, not a device which I would call very uncommon or
extraordinary. The datasheet says:
| 2-WIRE SOFTWARE RESET: After an interruption in protocol, power loss or system
| reset, 2-wire part can be reset by following these steps:
| (a) Create a start bit condition,
| (b) Clock 9 cycles,
| (c) Create another start bit followed by a stop bit condition as shown below.
| The device is ready for the next communication after the above steps have
| been completed.
> In any case, bitbanging this software reset should be a piece of cake. Really,
> really easy.
For sure, it's easy but I was hoping to get the job done by the USCI module
rather than writing delay loops (or waste a timer) in order to maintain the
correct timing.
> Do you know how to generate the "open colector output pin" behaviour with MSP?
> As in software I2C?
Sure, there's noting special about that.
Markus
Reply by ●December 18, 20092009-12-18
I meant for you to use bitbanging for the start-stop condition only which is
what you asked for, not the entire reset procedure which you hadn't
disclosed before.
I took a quick look at the datasheet and generally speaking I think you could use USCI for the first part of the reset procedure (sending start + clock cycles), and use bitbanging for the start-stop condition. I'm not sure if you would need to generate one extra dummy clock cycle.
If you only need to do this software reset on startup, there is no wasting a timer, and using/building a delay routine for this one time shouldn't be a problem. If you want, you can momentarily use a timer for this at startup (or the watchdog timer), but then you can release it for your application's purpose.
And timing is very relax on I2C transfers as far as I know. The only timings that have a maximum limit are slope (level transition) and response times. Therefore, the MSP being the master, you only have to ensure minimum timings for generating the start-stop condition.
Regards,
Michael K.
--- In m..., Markus Schaub wrote:
>
> Michael schrieb:
> >> I have a 24CXX I2C EEPROM which needs a special software reset procedure that
> >> involves sending a start condition directly followed by a stop condition. The
> >> EEPROM is connected to the USCI of a MSP430F54xx and is the only device on the
> >> bus. Having read the respective chapter in the user manual I would say that the
> >> USCI isn?t capable of sending the required sequence and that I have to reset the
> >> EEPROM by other means. I thought about powering the EEPROM up and down with a
> >> port pin because this is much more simpler and safer than the software reset
> >> procedure but this is not possible with the current revision of my hardware.
> >> Another solution would be to bit bang the reset sequence but this is pretty
> >> ugly, so I wonder if there is any trick to send the required sequence with the
> >> USCI.
>
> > Your requirement sounds strange but feasible. What's the EEPROM model or
> > datasheet link?
>
> It is an AT24C04B, not a device which I would call very uncommon or
> extraordinary. The datasheet says:
> | 2-WIRE SOFTWARE RESET: After an interruption in protocol, power loss or system
> | reset, 2-wire part can be reset by following these steps:
> | (a) Create a start bit condition,
> | (b) Clock 9 cycles,
> | (c) Create another start bit followed by a stop bit condition as shown below.
> | The device is ready for the next communication after the above steps have
> | been completed.
>
> > In any case, bitbanging this software reset should be a piece of cake. Really,
> > really easy.
>
> For sure, it's easy but I was hoping to get the job done by the USCI module
> rather than writing delay loops (or waste a timer) in order to maintain the
> correct timing.
>
> > Do you know how to generate the "open colector output pin" behaviour with MSP?
> > As in software I2C?
>
> Sure, there's noting special about that.
>
> Markus
>
I took a quick look at the datasheet and generally speaking I think you could use USCI for the first part of the reset procedure (sending start + clock cycles), and use bitbanging for the start-stop condition. I'm not sure if you would need to generate one extra dummy clock cycle.
If you only need to do this software reset on startup, there is no wasting a timer, and using/building a delay routine for this one time shouldn't be a problem. If you want, you can momentarily use a timer for this at startup (or the watchdog timer), but then you can release it for your application's purpose.
And timing is very relax on I2C transfers as far as I know. The only timings that have a maximum limit are slope (level transition) and response times. Therefore, the MSP being the master, you only have to ensure minimum timings for generating the start-stop condition.
Regards,
Michael K.
--- In m..., Markus Schaub wrote:
>
> Michael schrieb:
> >> I have a 24CXX I2C EEPROM which needs a special software reset procedure that
> >> involves sending a start condition directly followed by a stop condition. The
> >> EEPROM is connected to the USCI of a MSP430F54xx and is the only device on the
> >> bus. Having read the respective chapter in the user manual I would say that the
> >> USCI isn?t capable of sending the required sequence and that I have to reset the
> >> EEPROM by other means. I thought about powering the EEPROM up and down with a
> >> port pin because this is much more simpler and safer than the software reset
> >> procedure but this is not possible with the current revision of my hardware.
> >> Another solution would be to bit bang the reset sequence but this is pretty
> >> ugly, so I wonder if there is any trick to send the required sequence with the
> >> USCI.
>
> > Your requirement sounds strange but feasible. What's the EEPROM model or
> > datasheet link?
>
> It is an AT24C04B, not a device which I would call very uncommon or
> extraordinary. The datasheet says:
> | 2-WIRE SOFTWARE RESET: After an interruption in protocol, power loss or system
> | reset, 2-wire part can be reset by following these steps:
> | (a) Create a start bit condition,
> | (b) Clock 9 cycles,
> | (c) Create another start bit followed by a stop bit condition as shown below.
> | The device is ready for the next communication after the above steps have
> | been completed.
>
> > In any case, bitbanging this software reset should be a piece of cake. Really,
> > really easy.
>
> For sure, it's easy but I was hoping to get the job done by the USCI module
> rather than writing delay loops (or waste a timer) in order to maintain the
> correct timing.
>
> > Do you know how to generate the "open colector output pin" behaviour with MSP?
> > As in software I2C?
>
> Sure, there's noting special about that.
>
> Markus
>
Reply by ●December 22, 20092009-12-22
Michael schrieb:
> I meant for you to use bitbanging for the start-stop condition only which is
> what you asked for, not the entire reset procedure which you hadn't disclosed
> before.
>
> I took a quick look at the datasheet and generally speaking I think you could
> use USCI for the first part of the reset procedure (sending start + clock
> cycles), and use bitbanging for the start-stop condition. I'm not sure if you
> would need to generate one extra dummy clock cycle.
That's a nice method I didn't think of. I think I'm going for that but I'm still
a bit bothered by the fact that Atmel invented their own method for doing a
device reset rather than implementing the "standard" method.
Markus
> I meant for you to use bitbanging for the start-stop condition only which is
> what you asked for, not the entire reset procedure which you hadn't disclosed
> before.
>
> I took a quick look at the datasheet and generally speaking I think you could
> use USCI for the first part of the reset procedure (sending start + clock
> cycles), and use bitbanging for the start-stop condition. I'm not sure if you
> would need to generate one extra dummy clock cycle.
That's a nice method I didn't think of. I think I'm going for that but I'm still
a bit bothered by the fact that Atmel invented their own method for doing a
device reset rather than implementing the "standard" method.
Markus
