Vbat stops device running - STM32F207

[Tabulous]

I have a coin cell connected to Vbat, this for keeping RTC running and also backing up the BKPSRAM.

When running via debug on chibistudio all works ok.

If i stop the debug session and run the board in standalone mode, i.e remove debugger and cycle the power, the board does not run.......

Now if i remove the coin cell so Vbat is not powered, the board runs......

Why would Vbat be stopping the MCU running ?

[Giovanni]

Does enabling/disabling the RTC driver make any difference?

Giovanni

[Tabulous]

Does enabling/disabling the RTC driver make any difference?

Giovanni

Disabling the driver makes no difference.

But if pull the nRST to ground and then release it, the MCU starts to run. So i dont believe it is anything to do with the RTC driver.

[Tabulous]

some more feedback on this issue......

I now believe this is a Chibios issue.

To prove this i've written a small program and all it does is toggle a LED, there is no Chibios used in this program.

The MCU starts up fine even when VBat is connected, so based on this i can only assume that there is something in chibios.

So i went back to chibistudio and to the original program, if i remove the mac / ethernet, everything works voila...

So for some reason, the mac init is getting stuck in a while loop......

[Giovanni]

That while loop waits for an HW event that does not happen. Hardly a driver issue IMO, I could skip that loop but then the MAC driver would not work.

Giovanni

[Tabulous]

the issue is in this function

Code: Select all

uint32_t mii_read(MACDriver *macp, uint32_t reg) {

  ETH->MACMIIAR = macp->phyaddr | (reg << 6) | MACMIIDR_CR | ETH_MACMIIAR_MB;
  while ((ETH->MACMIIAR & ETH_MACMIIAR_MB) != 0)
    ;
  return ETH->MACMIIDR;
}

This is called by mii_find_phy, it gets stuck in the while loop

[Giovanni]

Apparently the MAC is unable to read the PHY register.

Giovanni

[Tabulous]

Apparently the MAC is unable to read the PHY register.

Giovanni

Because the this works when micro is under control of the debugger, i.e. power is on all psu line are stable

Do you think the MCU is trying to access the phy chip before it is ready from a cold start ?

One other thing to say is, i do have the physical reset line of the phy connected to a GPIO, did this so i could have a hard reset of the phy.

But maybe when the GPIO is configured by the pal driver, the time from the rst line been set high to the mac driver trying to access is not long enough

[Giovanni]

The MCU does that after it is out of the reset, you may try adding delays before halInit() and see if this makes a difference (note, you cannot use kernel functions there).

Giovanni

[Tabulous]

The MCU does that after it is out of the reset, you may try adding delays before halInit() and see if this makes a difference (note, you cannot use kernel functions there).

Giovanni

Adding a delay at the start of C main before halInit is called works, everything starts up ok, but its a nasty hack lol