IO port always readuing 0v in release mode.

[SSmit.13]

Hi

  I am using a STM32L433 and have a digital input pin, which is checked on bootup and enables the USB if 3.3v is in the pin.  When working in debug mode, it always works, but when I switch to release mode , using stm32CubeIDE , it always reads 0v, and my optimization is None. Below is my code .

RCC->AHB2ENR |= RCC_AHB2ENR_GPIOBEN; //Enable Port B clock

GPIOB->MODER &= ~GPIO_MODER_MODE12; //PB12 as input, check for usb interaction
inSetupMode=(GPIOB->IDR >> 12 )& 1;  //=1 when using USB

Can anyone let me know what the issue is?

Many thanks

Scott

[Tesla DeLorean]

Hard to know.

Enable the clocks early. There is a hazard enabling the clock and then immediately writing the peripheral registers.

Read back the RCC->AHB2ENR  /  _DSB()

[SSmit.13]

Hi ,

what is _DSB?

What do I check ? Is it if the B clock is enabled?

And if its not what do I do if its not enabled?

Sorry for all the questions.

Scott

[gbm]

Not a check, just small delay. Also, I would suggest adding some small delay between MODER setting and reading the IDR.

[Tesla DeLorean]

Potential with all clocks, whilst design is synchronous, probably a couple of gates deep, to reset and start properly. 

DSB is a fencing instruction, clearing the pending write buffers

https://developer.arm.com/documentation/dui0489/c/arm-and-thumb-instructions/miscellaneous-instructions/dmb--dsb--and-isb

https://www.eevblog.com/forum/programming/stm32-__dsb()-vs-reading-back-register/

The HAL has a lot of lag and function calls, where as optimized register level code will potentially get you back-to-back pipelined writes, hence the hazard.

See how the HAL reads back the RCC register, this forces the pending writes to complete.

[SSmit.13]

Many thanks for the reply. I will add a delay.

Thanks

Scott

[SSmit.13]

Many thanks for your reply.

I havent come across this before, do I call it for all clocks, or is it 1 command takes care of it all?

I can add "__DSB();"  line to my code, is that all is needed?

Regards

Scott

[SSmit.13]

I added the line:

__DSB();

after the clocks being enabled, but never made a difference.

But when I added a 2ms delay after GPIOB->MODE and this worked.

Where do I add the DSB command, and is it just the DSB() on its own?

CHeers

Scott

[Tesla DeLorean · Accepted solution]

After the write

See how HAL does the clock enables, reads back to insure writes complete first, as forces IN-ORDER-COMPLETION for the write buffers and pipeline, and adds perhaps 4 bus cycles to the transaction.

#define __HAL_RCC_GPIOB_CLK_ENABLE()           do { \
                                                    __IO uint32_t tmpreg; \
                                                    SET_BIT(RCC->IOPENR, RCC_IOPENR_GPIOBEN); \
                                                    /* Delay after an RCC peripheral clock enabling */ \
                                                    tmpreg = READ_BIT(RCC->IOPENR, RCC_IOPENR_GPIOBEN); \
                                                    UNUSED(tmpreg); \
                                                  } while(0U)