-
Take the ELF file and run "arm-none-eabi-objdump -d file.elf > file.txt" This will give you the disassembly.
IDEs suck. -
Does the following picture tell that what went wrong?
The address 0x40012C00 is the start of TIM1 register: it should not appear in the shown stack trace!
Of course, you'll find no code there.
The address below could be legit (as 0x00000000 is an alias for the flash at 0x08000000 in normal boot mode).
Moreover, the "Signal Handler called at 0xFFFFFFF1" is quite suspect: the value of 0xFFFFFFF1 is an EXCEPTION_RETURN (loaded in LR when entering exceptions) and means that the CPU was already in handler mode when fault hit, i.e., already in an interrupt servicing routine or in a fault handler.
In the second case the processor enters lockup (only reset and NMI accepted) and the stack unwinding in gdb gets very confused (at least it used to - not sure this is still the case, but it looks like).
You might need to follow ataradov's instructions to unwind the stack manually. -
With a debugger, you would look at Hardfault Status Register and others. If there is some actual reason not to use a debugger, you can just print those interesting registers to UART as well in your hardfault handler (make it an infinite loop which prints every second so that you don't miss the printout when it happens).
I second the suggestion to print a stack trace when a hard fault occurs. In my own code I print the last 16 words (32 bit) on the stack from the hardfault handler using a piece of code that takes over a UART and controls it directly to output characters. From there I pick values that point to flash or RAM to pinpoint which function the processor was executing. A map file is required for this. This has helped me to solve pointer corruption problems quite a few times. Using a debuggen has proven to be less helpfull in these cases because the debugger tries to interpret a stack frame that is in an interrupt context.
Also, given the erratic behaviour I'm not ruling out the OP has a hardware problem so it would be good if the OP can share the processor part of the schematics and the board layout. -
View disassembly is to be used only in a live debugging session.
Open project properties, select All configurations, go to C build options:
- MCU post build options, tick Generate list file.
- MCU GCC compiler, debugging, set debug level to max.
That's it, after building you'll have a .list file with the asm.
I like IDEs
-
The address 0x40012C00 is the start of TIM1 register: it should not appear in the shown stack trace!
Of course, you'll find no code there.
The address below could be legit (as 0x00000000 is an alias for the flash at 0x08000000 in normal boot mode).
Moreover, the "Signal Handler called at 0xFFFFFFF1" is quite suspect: the value of 0xFFFFFFF1 is an EXCEPTION_RETURN (loaded in LR when entering exceptions) and means that the CPU was already in handler mode when fault hit, i.e., already in an interrupt servicing routine or in a fault handler.
In the second case the processor enters lockup (only reset and NMI accepted) and the stack unwinding in gdb gets very confused (at least it used to - not sure this is still the case, but it looks like).
You might need to follow ataradov's instructions to unwind the stack manually.
Interesting, I don't use TIM1 at all. Only TIM6 & 7. I've got the list file like DavidAlfa suggested. I looked for the TIM1 register 40012C00 and found three occurences.Code: [Select]/* Change the htim state */
htim->State = HAL_TIM_STATE_READY;
8004968: 2301 movs r3, #1
__HAL_UNLOCK(htim);
800496a: 2000 movs r0, #0
htim->State = HAL_TIM_STATE_READY;
800496c: 702b strb r3, [r5, #0]
__HAL_UNLOCK(htim);
800496e: 7020 strb r0, [r4, #0]
return HAL_OK;
}
8004970: bdf0 pop {r4, r5, r6, r7, pc}
8004972: 46c0 nop ; (mov r8, r8)
8004974: 40012c00 .word 0x40012c00
8004978: ff0fffff .word 0xff0fffff
800497c: 40000400 .word 0x40000400
8004980: 40014000 .word 0x40014000
08004984 <HAL_TIMEx_CommutCallback>:
8004984: 4770 bx lr
08004986 <HAL_TIMEx_BreakCallback>:
8004986: 4770 bx lrCode: [Select]/* Check if the update flag is set after the Update Generation, if so clear the UIF flag */
if (HAL_IS_BIT_SET(TIMx->SR, TIM_FLAG_UPDATE))
800489a: 6903 ldr r3, [r0, #16]
800489c: 4213 tst r3, r2
800489e: d002 beq.n 80048a6 <TIM_Base_SetConfig+0x7e>
{
/* Clear the update flag */
CLEAR_BIT(TIMx->SR, TIM_FLAG_UPDATE);
80048a0: 6903 ldr r3, [r0, #16]
80048a2: 4393 bics r3, r2
80048a4: 6103 str r3, [r0, #16]
}
}
80048a6: bd10 pop {r4, pc}
80048a8: 40012c00 .word 0x40012c00
80048ac: 40000400 .word 0x40000400
80048b0: 40002000 .word 0x40002000
80048b4: 40014000 .word 0x40014000
80048b8: 40014400 .word 0x40014400
80048bc: 40014800 .word 0x40014800
80048c0: fffffcff .word 0xfffffcff
080048c4 <HAL_TIM_Base_Init>:
{
80048c4: b570 push {r4, r5, r6, lr}
80048c6: 0004 movs r4, r0
return HAL_ERROR;
80048c8: 2001 movs r0, #1
if (htim == NULL)
80048ca: 2c00 cmp r4, #0
80048cc: d023 beq.n 8004916 <HAL_TIM_Base_Init+0x52>
if (htim->State == HAL_TIM_STATE_RESET)Code: [Select]800466e: 4770 bx lr
__HAL_TIM_ENABLE(htim);
8004670: 681a ldr r2, [r3, #0]
8004672: 4302 orrs r2, r0
8004674: 601a str r2, [r3, #0]
return HAL_OK;
8004676: 2000 movs r0, #0
8004678: e7f9 b.n 800466e <HAL_TIM_Base_Start_IT+0x46>
800467a: 46c0 nop ; (mov r8, r8)
800467c: 40012c00 .word 0x40012c00
8004680: 40000400 .word 0x40000400
8004684: 40014000 .word 0x40014000
8004688: 00010007 .word 0x00010007
0800468c <HAL_TIM_Base_Stop_IT>:
{
/* Check the parameters */
assert_param(IS_TIM_INSTANCE(htim->Instance));
/* Disable the TIM Update interrupt */
__HAL_TIM_DISABLE_IT(htim, TIM_IT_UPDATE);
800468c: 2101 movs r1, #1
800468e: 6803 ldr r3, [r0, #0]
Is there anything suspicious here?
-
If you look at the stack as I described, you will know where it failed and why. Then you can look at the specific piece of code instead of guessing which one may be wrong.
There is not likely to be a mistake in the compiler generated code, so looking at those specific fragments is pointless. You may have some out of bounds access and it just happens to fetch a random value from the memory. That memory is not at fault here. -
I guess DISP_PW pin is controlling the power to the display.
Might it be crashing due a VDD trasient? Since the display has its own caps, the initial inrush current might be able to cause a voltage glitch.
Put a 10uF electrolytic cap just before the switching device (In the STM32 side) and check if still happening.
Also since this is a personal project, consider attaching the schematic and CubeIDE project, will be much easier to find any design/program flaw. -
This is now solved and it was indeed hardware issue. 1.54" Oled display HS154L03B2C01 took so big current spike that when MCU switched P-Fet on it crashed the MCU. Even afterwards added 10uf cap didn't fix it. Power supply for the display changed from 3.3V to 5V and 10uf cap added to the supply now.
Thank you all for being so helpful and special thanks to DavidAlfa for debugging.. Fantastic that there are so many kind people willing to help when someone is banging their head on the wall for weeks not figuring it out by theirselves.
-
BTW, do you have Brown-Out Detector enabled? It's usually a good idea to enable it and setup it with highest voltage (closest to supply rail) possible, e.g. 3.0V for a 3.3V rail - I don't know what settings are available for STM32G0, though. This way, you (usually) get a clean reset instead of the microcontroller doing some random and hard-to-debug shit.
Non-current-limited, hard-on P-channel MOSFETs are quite problematic if the load has almost any capacitance (beyond some trivially small value like 0.1µF). Think about it - even if you add 10 times the capacitance before the switch, the charge divider formed by the two capacitors would still cause a 10% voltage dip. If you have a spare IO pin, you can use it to do a precharge step, using another switch but with series resistance. Best option is a high-side load switch IC with built-in inrush current limitation. -
OLED displays require a boost converter, so if you use a ready-made module and unless they have implemented some soft-start, the current peak when powering them on can be quite high.
-
Yeah, the oled made a nasty vdd glitch
.
I suggested making the fet switch slowly with 10-22K Rgate + 100nF, that way it would take 5-10ms to switch.
But the display had its own LDO, so in the end the "fix" was to connect it to 5V directly, avoiding disturbing the 3.3v rail.
Any small spike won't get through the 3.3V LDO and reset the STM32.
Still, I would make the fet switch slower, voltage glitches are never good. -
I suggested making the fet switch slowly with 10-22K Rgate + 100nF, that way it would take 5-10ms to switch.
This is OK, but it's a good idea to do at least a napkin calculation on SOA. For small MOSFETs (those rated to say 1-2A) and large capacitances (maybe 100µF or so), the power dissipated in the MOSFET is too much for the tiny die, and kills the MOSFET. It's pretty simple to approximate switching time from I_gate * t_sw = Qg_tot + Q_external, and then look at the SOA curves if the MOSFET can take this I_gate for t_sw; if not, pick a larger MOSFET. -
That's why I suggested this, 100ma, 5-10ms shouldn't cause any issue.
If It was 100amps I wouldn't! -
Dear All,
So I felt to this same trap twice now.
I also had active 5V buzzer on the board, controlled by low side N-Fet AO3400A. Had 620r series resistor between gate and mcu pin and 100k pull down on mcu pin. Odd behavior that debugger disconnected sometimes and second counter got crazy values whenever it didn’t completely crash. Changed from the buzzer control to the onboard led and it worked like it should. Buzzer is rated for <30mA. I’m bit stumbled how even that is causing the MCU to go crazy. I got the manual recommended 4.7u and 0.1u caps right next to VDD/VDDA pin, 0.1u cap shared on VREF+ and VBAT pins and all these connected to 3.3V net. I got the exact same layout and setup (except the vref and vbat as they were missing) on the STM32G050 and it drove that buzzer with no issues. Could it be that this STM32G070CBT6 is somehow more sensitive or something? Should I in the future always include RC delay on every STM32 design which drives FET? Or add more capacitance to the MCP16251 step up converter output? Now 10uf like suggested in datasheet and 4.7uf in battery input side.
Actually the pcb is bit different on this new design. It’s six layer pcb, with following layer stack up. But should this basically be even better?
signal
gnd
3.3 VDC
5 VDC
gnd
signal
On older design had four layers.
signal
gnd
5 VDC
signal
Thank you in advance -
At this point, it would be easier to see if you just post the full schematic (and picture of layout).
-
Agreed. And using 6 layers seems excessive for this design; it is not going to solve any of the problems. I second the suggestion others made to use current limited load switches instead of MOSFETs.
-
Probably lacking capacitance in the 3.3V rail? 10uf + 100nF at the LDO + 100nF on every device.
You said there was 300mA at the LDO output, which might be close to the limit for a lot of regulators, so any extra current spike will result I current limitation and voltage drop.
Yeah you should post the schematics once for all instead telling "I'm having a strange issue".
Also, making a new pcb each time is just wasting money, make any required modifications in the current board, like adding caps, cutting traces, adding wires... It's fine!
When you get it working, then order the new pcb! -
Extra capacitance is not going to help. Charging a 1uf cap from a 10uf cap gives you a 10% voltage drop. But chances are the capacitance is much higher on the device that gets turned on. Like 10uf or tens of uf. You'd need to have 1000uf to 10,000uf on the board to prevent excessive (>1%) drooping of the rails. A load switch with soft-start / current limiting is the way to go.
-
Ok, sorry. Here's the schematics and picture of the pcb. Display portion is bit changed according to the comments, but I haven't yet received the PCB yet which is according to the new schematic..
-
Just make fets switch slowly!
-
Was just wondering, were the schema and layout otherwise ok? I'd appreciate to hear some feedback to further learn...
Did I understood correctly the delayed switching, whether below is correct?
-
15K or even higher might be required if the loading device has a large capacitance.
If the cost of the extra resistor+cap gets close to a current-limited switch, it's no brainer here!
But did even a buzzer reset your system?
You induced a problem by choosing fets conducting extremely well at low VGS (24 mOhm at 2.5V).
Do you need such low RDS to power a oled screen? I don't think so.
The problem? It will conduct so fast and so much, the charging current will be huge, causing all the issues you're having.
Did you measure the current at VDD rail? Was it 300mA? Well, the STLQ015 LDO is rated for 150mA!
Internally limited to 250-350mA, so you might be in the limit, any extra load causes voltage drop and it won't be able to respond properly to any small current surge.
As the OLED screens ususally carry their own LDO, just power it from 5V directly (As already talked).
Do you have oscilloscope?
If so, make a single run triggered by the gpio, second channel connected to VDD.
You'll see how VDD reacts to the load, if the voltage drop is still too large, increase the resistor.
Was that 10uf cap you used ceramic or electrolytic?
Ceramics have extremely low esr, so the current spike can be short and huge, beyond what most electrolytics can filter.
Try adding several 1uF ceramics here and there!
Also: Learn about filtering chokes / ferrite beads. Adding a 1K+ @ 100MHz choke will help filtering any fast trasients.
But can be like opening a can of worms, adding big ceramic caps to them or certain current patterns can make them oscillate!
https://www.mouser.com/ProductDetail/Fair-Rite/2508052026Y1?qs=sGAEpiMZZMt1hubY80%2Fs8OaNS%2FJrXGrqqm6ynnsmRzk%3D
https://www.mouser.com/ProductDetail/Murata-Electronics/BLM21HE472SN1L?qs=sGAEpiMZZMt1hubY80%2Fs8KH3ycnB7WcGvEtoVdG6EB4g77W1AEfufA%3D%3D
https://www.mouser.com/ProductDetail/Murata-Electronics/BLM31KN102SH1L?qs=sGAEpiMZZMt1hubY80%2Fs8DE23zOR%2FvJ90O%2Fye4ApNH4cE%252BJSpGa1AA%3D%3D -
Indeed the buzzer does also reset or cause havoc on the system. That’s what I tried to say that this thing got me twice (on post #63) and that’s why I was wondering that is there some other detrimental flaw in my design or is it just cursed? Ruling out any code related issue, changing the output to the led cured the issue with the buzzer.
You induced a problem by choosing fets conducting extremely well at low VGS (24 mOhm at 2.5V).
Interesting.. Well, to be true, I've searched the smallest RDSon fet's available and invested on them. Due to my ignorance it seems it bite me. Still it beats me why the buzzer work with the G05 and with G07 it doesn't?
Do you need such low RDS to power a oled screen? I don't think so.
The problem? It will conduct so fast and so much, the charging current will be huge, causing all the issues you're having.Quote from: DavidAlfaDid you measure the current at VDD rail? Was it 300mA? Well, the STLQ015 LDO is rated for 150mA!
No I haven't measured that. I can only see that the whole system draw bit over 10mA max. seen from the lab power connected to the J4 battery connector. That 300 mA was what I remembered that this STLQ015 had max output, but you're right it's only 150mA. Still it should be plenty when both 5V and 3.3V net combined draw decade less. However, I'm not able to see the sudden current spikes. Lab power is quite slow to react.
Internally limited to 250-350mA, so you might be in the limit, any extra load causes voltage drop and it won't be able to respond properly to any small current surge.
As the OLED screens ususally carry their own LDO, just power it from 5V directly (As already talked).Quote from: DavidAlfaDo you have oscilloscope?
I do have. On G070 datasheet it says "Voltage range: 2.0V to 3.6V". So voltage drop not exceeding 1.3V on 3.3V rail is acceptable?
If so, make a single run triggered by the gpio, second channel connected to VDD.
You'll see how VDD reacts to the load, if the voltage drop is still too large, increase the resistor.Quote from: DavidAlfaWas that 10uf cap you used ceramic or electrolytic?
The one I added to the OLED output was electrolytic and it didn't cure the problem on display turning on.
Ceramics have extremely low esr, so the current spike can be short and huge, beyond what most electrolytics can filter.
Try adding several 1uF ceramics here and there!
What comes to the current limiting fet's. I’m not sure have I searched with wrong keywords but current limiting FET’s eg. 8 pin soic MAX890L cost over 3€ so it’s pretty steep compared to any fet+res+cap combination… And that still needs one extra resistor which dictates the current limit. Any suggested parts for current limiting N and P fets?
-
Still, a buzzer shouldn't reset your system so easily.
How about 100uF electrolytic after the LDO? -
Buzzer isn't a large capacitive load. Something else must be going on.