Migrating from MSP430F5419 to MSP430F5419A

The non-A and A devices have more differences than originally documented in teh migration guide.

There are some differences in handling the clocks in LPM situations, up to the crystal handling.

(IIRC, someone had discovered that on an A device a crystal gets shut down in LPM which stays active on the non-A with identical firmware binary)

The REFMSTR bit just controls who is controlling the reference. It does not itself enable or disable the reference. Clearing the bit turns the referencecontrol back to the ADC12 module where it is on the non-A (unfortunately, the default has the contol on the REF module, which makes the default situation icompatible to the non-A)

Did you compare the errata sheets of the two?

While it is a good idea to have PMMCOREV on the same level on both devices, I can imagine that the lower power consumption of the 'A's partly comes from the fact that you can use a lower PMMCOREV setting on low frequencies (which you cannot on the non-A)
Maybe the upgraded core for higher maximum speed consumes actually more if run on low frequencies without lowerign PMMCOREV.

IIRC, on the non-A the internal RST pullup is not active by default. I'm not sure about the A, but if it is active there (as it is for almost all other 5x family members), this could make a difference too.

Thanks for responding

As you mention there seems to be more differences between the A and non-A device, than stated in the migration guide. One particular behavior that we have noticed is that some errata which doesn’t affect the non-A suddenly makes a huge impact on the A-device. For instance the PMM9 errata note; on the A-device we must conduct the workaround suggested by TI, but on the non-A device no workaround is needed. Regarding other errata notes we have studied the differences, but can’t find anything that should be in conflict with our application code.

We are not using the internal reference in our design (i.e. switched off in ADC12 module), and in accordance with migration guide REFMSTR is set to ‘0’.

I agree that enabling lower core voltages might increase the power consumption at identical PMMCOREV levels. However the datasheet clearly specify that the current  consumption for the A-device is less than non-A during any circumstance, also when the A-device is run at PMMCOREV_2.

In order to eliminate possible software bugs in our application code, I used the MSP430F5438 Experimenter Board and software examples from TI to do a comparison of the two devices. I made the necessary changes to be able to run the code at msp430f5419(A) and verified the current consumption for the two devices using the “PMM-MCLK” option in the example code. The result was more or less identical to the behavior that we experienced in our application. When running the controller at identical PMMCOREV (2) and frequency (1MHz) the A-device consumes approximately 70uA more than the non-A. The difference is proportional to system frequency i.e. at 16MHz the difference is 1mA. Even if we use the lowest PMMCOREV settings for the A-device, it consumes more current (10-20uA) than the non-A.

 Regarding the RST pin we are using an external pull-up and decoupling capacitor, hence the internal pull-ups are disabled. Enabling the internal pull-up made no difference to the current consumption.

Frankly I’m beginning to run out of ideas how to reduce the overall current consumption for the A-device, so any help regarding this problem is highly appreciated.

Regards
os

Olav Staberg said:

Regarding the RST pin we are using an external pull-up and decoupling capacitor, hence the internal pull-ups are disabled. Enabling the internal pull-up made no difference to the current consumption.

On the non-A the pullup on RTS is disabled by default (which makes it pretty much useless), on teh A devices, ti is active after reset. So you might want to disable them.
However, the additional consum,ption wouldn't scape with speed. SO the reason must be a different one.

Soem thing that has changed with the last silicon revision is the FLASH buffer. As before 12/2010 had problems when flash wasn't accessed of rsome time. So the flash fetch buffer has been reworked on teh latest silicon. It might cause a higher current consumption that would scale with speed. Just an idea. Can you alter your program so that it runs in RAM during measurement? Is there still a difference in consumption then? If so, then the flash is the problem. If not, it must be the core and/or the SVS/PMM module.