This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F5342: Errata PORT24

Part Number: MSP430F5342

Dear TI experts

Now I have some problems when I test the MSP430F5342.

According to the slaz278ab,errata PORT24 says that there will be an increased current consumption because of the internal floating pads.

And Workaround gives the code in C to avoid the increased current consumption.

But the "#define INIT_MEMORY_ADDR  0x0204" in the slaz278ab->PORT24,as follow:

which differs from the "#define INIT_MEMORY_ADDR1 0x0206" in the slac504g\MSP430F534x_Code_Examples\MSP430F534x_LPM3_01.c,as follow:

Which one should I choose for the solution to the errata PORT24.

Thanks in advance for your help.

Best Regards.

  • Hello,

    the PORT24 erratum is related to the point, that all not terminated IOs, means GPIOs set to input, which is the default state of all GPIOs after power cycle, of the MSP430 will result in floating nodes, which dependent on the resulting voltage of the same will cause cross currents from supply voltage to GND through the respective complementary transistor stage, as the transistors will not be perfectly shut off. This current depends on the voltage, temperature and the transistor parameters, and can reach as an order of magnitude up to 200µA. So far for the physics behind this phenomenon.

    Now with the MSP430F5342 48-pin RGZ package, not all GPIOs are connected to physical pins, as the package does not offer as many as required. Based on the erratum information, these GPIOs available on chip but no connected to physical pins of the package, are not terminated by the integrated boot code in this device.

    This means they cannot be terminated by external circuitry, as you would do it if all GPIOs would be connected to physical pins. That's why according to the erratum you need to do it in your own code. The termination of GPIOs without external components can be done in two ways. The one option is to switch the respective IO to output direction. This way its switched either to output high or output low, means the node does not float anymore and one of the transistors in the respective transistor stages is perfectly closed, means there is no cross current through the stage, and thus not degrading your LPM performance.

    The second option is to activate the internal resistor, and again independent of configuring it to pull-up or pull-down, it will tie the voltage at the GPIO to either VCC or GND, which means the GPIO is again terminated correctly.

    The Erratum and the recommended is basically addressing this. Now to the discrepancy. Looking into the device datasheet you can on one hand figure out, which GPIOs are not available at physical pins in case of the RGZ package, and on the other hand you can check the addresses of the SFRs for the control of the GPIO state.

    Looking at P1 and P2. e.g. one can see P1 is available completely at physical pins, with P2 it is just P2.7. Thus in case of P2 P2.0-P2.6 need to be terminated internally. When writing in 16bit format to P1/P2 this would 0x7F00 (as in the erratum workaround). Looking into the datasheet's table 6-25 you can see the P1DIR is located at 0204h. At 0206h the register for P1REN is located. So when using the recommendation from the erratasheet the termination would be done by setting the GPIOs to output direction, while with implementation of the code example the termination would happen by activating the internal resistors. Both termination options work. So from this perspective both are correct.

    But there seems to be something wrong with the pointers in C, as according to the assembler version and datasheet the register locations are 204h, 224h, 244h and 264h. I double check on this and come back to you.

    Best regards

    Peter

  • Thanks,Peter.

    Great TI experts!

  • Hello,

    to close the open point on the addressing:

    The addition of the offsets 0x10, 0x20 and 0x30 is interpreted correctly by the compiler, as with MSP430 the unsigned integer is 16bit wide. Thus adding 0x10 means adding 0x10 words. That's where the multiply by 2 (bytes) comes from, resulting in addressing +0x20, 0x40 and 0x60.

    Best regards

    Peter

**Attention** This is a public forum