MCU-PLUS-SDK-AM243X: ADCPowerUp() leads to a data-abort

Hi Felix,

It sounds like the ADC MMR is not ready when you try to write to the register too fast (like boot directly from flash). Can you try to add some delay before the first ADC MMR write? It usually need some time from the analog module reset to actually access it.

Best regards,

Ming

Hey Ming,

I cite you from that other thread, so we can keep going here:

Hi Felix,

Here is the ADC module initialization procedure:

System_init
   PowerClock_init(void)
      Module_clockEnable();  <-- where ADC module clock is enabled

adc_singleshot_main
   App_adcInit
      ADCClearIntrStatus 

         HW_WR_REG32(baseAddr + ADC_IRQSTATUS, intrMask);  <-- first ADC MMR write
      ADCPowerUp
         HW_WR_FIELD32(baseAddr + ADC_CTRL, ADC_CTRL_POWER_DOWN, ADC_CTRL_POWER_DOWN_AFEPOWERUP);
      ClockP_usleep(5U);
      ADCInit(baseAddr, FALSE, 0U, 0U);

I would put some delay between System_init() and adc_singleshot_main() or in the beginning of App_adcInit() .

Best regards,

Ming

So as mentioned there is already some time between the call to System_init and the ADC set-up in our system since there is other initialization-stuff done in between. We are not using the examples but our own code. The setup-routine-calls are the same as you wrote:

            /* Clear All interrupt status */
            ADCClearIntrStatus(setAdcModuleValues.adcBaseAddress, ADC_INTR_STATUS_ALL);

            /* Power up AFE */
            ADCPowerUp(setAdcModuleValues.adcBaseAddress, TRUE);

            /* wait some time for power up. this is from sdk example */
            ClockP_usleep(5U);

            /* adc internal calibration values. example does not show detailed meaning of this */
            uint32_t calibration = 1;
            uint32_t errOffset = 1;
            /* Do the internal calibration */
            ADCInit(setAdcModuleValues.adcBaseAddress, FALSE, errOffset, calibration);

we are setting "1" to calibration, could this be an issue? there is no more explanation and description in the sdk.

For explanation why a delay is not a solution for us:

We use an abstraction-layer for our drivers and we also have an ADC-Driver. We initialize our SW in different components at startup with different initialization stages. For example the System_init is done directly from start and the ADCDriver is initialized later on when our so called "device resources" are created. The driver is an own entity and setting a delay before would slow down our whole startup-process. This is not a solution.

We may find a solution with an explicit instantiation but it's not ok if every user of the ADC must insert a delay manually or think about a delay in a function where you do not expect a delay or call the function where you normally do not initialize stuff anymore just because of that timing-issue. This will lead again to some aborts which you do not see in CCS but only when booting from flash, in case you miss to set the delay...

And just out of interest: Are there more SoC-Entities which can have this problem? It would be really uncomfortable if we run into another boot-from-flash-abort-problem because of some timing issues that are not documented in the TRM.

I will now try to add a delay to see if this helps and keep you updated but aren't there other possibilities? Anyways: just running into an abort is not a good solution I guess, since it took us a week to debug this.

ok, so I tried the delay. first with 100 ms, second with 1000 ms and third with 10000 ms (between System_init() and calling the init-sequence for the ADC). It did not help. Still the device aborts in the ADCPowerUp. So it's not a timing issue between the System_init() and the ADC-init it seems

Hi Felix,

I forwarded this thread to our bootload expert in software team for further assistance.

Thanks!

Ming

Hi Felix,

I have unlocked this thread. Please contact our bootloader expert in software team for further assistance.

Best regards,

Ming

Hey Ming, I will create some new debug-session-options with Ankur.