2020-05-15 01:15 AM
seems to be the same source as (but question is closed without any answer or workaround):
workaround: reconfigure with Outputlevel 1 and set Outputlevel to 0 after reconfiguration!
2020-05-15 01:33 AM
edit: the documentation in the reference manual seems to be copied from F1; AFIO_MAPR i.e. does not exist in L471
2020-05-15 03:45 AM
> the documentation in the reference manual seems to be copied from F1; AFIO_MAPR i.e. does not exist in
Just for the laughs:
@Imen DAHMEN , can you please have a look at the latter issue.
JW
2020-05-15 04:00 AM
Concerning the original problem - so you are using a 'L471?
How EXACTLY do you change the PA15 configuration? If you are using some "library", can you please show us the actual code in that "library" that actually changes the configuration?
JW
PS. https://community.st.com/s/question/0D50X00009XkaIP/using-pa15-as-an-io-on-stm32f373-swjcfg
2020-05-15 06:42 AM
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_15, GPIO_PIN_SET);
GPIO_InitStruct.Pin = GPIO_PIN_15;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_15, GPIO_PIN_RESET);
^^ this version works
the next version failed, time by time (our system is 99,99% in standby mode; in our case the error occures in times between 15min and 3 hours):
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_15, GPIO_PIN_RESET);
GPIO_InitStruct.Pin = GPIO_PIN_15;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
There is an external pullup on this line, otherwise the system won't work with standby ;)
2020-05-15 06:44 AM
yes, STM32L471
2020-05-15 06:55 AM
> There is an external pullup on this line, otherwise the system won't work with standby ;)
I don't understand - what happens if the external pullup is not there?
What is connected to PA15, exactly?
Is debugger connected when the problem occurs? If yes, does the problem occur also when the debugger is not connected?
How do you know it's hardfault? Do you have some specific hardfault handler written? Can you debug/output e.g. stack content in hardfault and then check in the disasm, what was the cause of the hardfault?
JW
2020-05-15 06:56 AM
The hardfault occures in HAL_GPIO_Init:
if((GPIO_Init->Mode == GPIO_MODE_OUTPUT_PP) || (GPIO_Init->Mode == GPIO_MODE_AF_PP) ||
(GPIO_Init->Mode == GPIO_MODE_OUTPUT_OD) || (GPIO_Init->Mode == GPIO_MODE_AF_OD))
{
/* Check the Speed parameter */
assert_param(IS_GPIO_SPEED(GPIO_Init->Speed));
/* Configure the IO Speed */
temp = GPIOx->OSPEEDR;
temp &= ~(GPIO_OSPEEDR_OSPEED0 << (position * 2));
temp |= (GPIO_Init->Speed << (position * 2));
GPIOx->OSPEEDR = temp;
/* Configure the IO Output Type */
temp = GPIOx->OTYPER;
temp &= ~(GPIO_OTYPER_OT0 << position) ;
temp |= (((GPIO_Init->Mode & GPIO_OUTPUT_TYPE) >> 4) << position);
GPIOx->OTYPER = temp; //one cycle after that instruction
}
One cycle after the marked instruction, it will call the hardfault handler. The flags are set to "undefined instruction".
The same asm-instructions are called many times before and afterwards.
2020-05-15 07:04 AM
> I don't understand - what happens if the external pullup is not there?
in standby/shutdown/after reset the JTAG-pins are at default state. if you have 1 or Z, it works. 0 is not allowed.
> What is connected to PA15, exactly?
resistor and transistor. nothing special, no high current or something like that
> Is debugger connected when the problem occurs? If yes, does the problem occur also when the debugger is not connected?
it works with and without debugger
> How do you know it's hardfault? Do you have some specific hardfault handler written? Can you debug/output e.g. stack content in hardfault and then check in the disasm, what was the cause of the hardfault?
yes, all done. the event log logs all registers, ...
2020-05-15 07:52 AM
>> I don't understand - what happens if the external pullup is not there?
>
> in standby/shutdown/after reset the JTAG-pins are at default state. if you have 1 or Z, it works. 0 is not allowed.
Is this documented anywhere. or is this your experience?
What exactly happens, if it's in 0?
> One cycle after the marked instruction, it will call the hardfault handler.
This does not make much sense... that line just changes OTYPER, from 0 to 0...
Can you please read out GPIOA_OTYPER before that crash and log, or check if it is indeed 0?
>> How do you know it's hardfault? Do you have some specific hardfault handler written? Can you debug/output e.g. stack content in hardfault and then check in the
>> disasm, what was the cause of the hardfault?
>>
> yes, all done. the event log logs all registers, ...
Can you please post relevant portion of that log, together with relevant portion of the disasm at around the problematic instruction?
Thanks,
JW