LSE false enabled, PC14 wrong reading

[andreas2399]

We discovered spurious Errors (every half a year) on reading out the GPIO Pin PC14 on a STM32F427ZIT6.

The Pin

• is not connected on the PCB itself.
• Is configured as Input with PullUp

And reads in perfectly the High state from the PullUp in 99.99% of the cases.

Now the very rare and not reproducible erroneous behavior:

The Pin reads back 'low'.

Therefore we added some checks on startup that will check the LSE bit and print it out if there are issues. LSE is disabled in the FW itself and there is no FW code targeting that.

We discovered that the BDCR Register has the LSE enabled (which we don’t to in the FW) & which we also verify now on startups.

Antoher weird thing is that the BDCR reports that the LSE is stable (LSERDY bit)

 PC15 is also not connected on the PCB.

Here a dump of the registers while the error is present.

BDCR:             0b1100000111  

BDCR.LSEON:0b1 

PIN:

MODER:           0b10101010000000111111111111 

OTYPER:        0b1000000000 

PUPDR:        0b100000000000000000000000000 

IDR:           0b101100000000

As said, this issue is happening very seldom & not reproducible at all.

We thought it could happen due to a undiscovered dangling pointer itself that actives the LSE, but now we have seen that the LSERDY was also set - which is HW controlled.

I could not find any reports in the STM Community related to that.

I would appreciate some hints / information on that.

br Andreas

[waclawek.jan]

I'd say it *is* a dangling pointer.

Don't pay much attention to LSERDY - if the pins are unconnected, they are floating, high impedance, and I believe there may be enough noise on the board so that it experiences some input pulses (the LSERDY detection is just a counter, no sophisticated timing analysis). Also note that LSEBYP is set to 1 too, and maybe in that case LSERDY does not wait for the detection at all (this is not very clear from the documentation, but there were some hints toward this notion on this forum before).

I know that debugging rarely occuring errors are PITA, but for me, simulating an overload by dumping all possible data into the input communication channels at the highest possible speed, and wiggling all input pins (including the communication ones, simulating a bunch of errors) by a simple automated jig, worked in the past. There may be more sophisticated methods of course, resulting from intimate knowledge of the software; but always leave room for the unknowns. Unexpected writes can be caught using data breakpoints in debugger.

JW

[waclawek.jan]

Hi,

did you solve this problem?

JW

[andreas2399]

Hi

Issue is still present.

It still is hard to reproduce.

So no progress on that topic from our side.

br Andreas

[waclawek.jan]

Hi Andreas,

thanks for the reply.

A couple of ideas, maybe not very useful, should you revisit the issue:

- if you use some of the SPL or Cube functions which manipulate the clocks and potentially write to RCC_BDCR, make sure the structure used as parameter to that function call is fully initialized

- you may want to check LSEON but after each function call which potentially accesses BDTR, or maybe even any RCC register

- maybe hooking up to the interrupt enabled by RCC_CIR.LSERDYIE could help to localize the circumstances when LSE gets enabled (although the interrupt comes obviously only after some number of pulses occurs on the given pin, so it's not that instantaneous s one might wish here)

JW