Reverse engineering FNIRSI-5012H

[ataradov]

It is possible that not all MCUs are tolerant to overclocking. But I would investigate this further.

Is this picture with the clock configuration disabled? And without disabling it does not work at all?

The project does have hard fault handler installed and it would print the information if this was an actual hard fault. So it just gets stuck in some place in the application logic. But if this is with the slow clock, then I don't know if this is to be expected. I never tried it that way.

One thing I can suggest right away is in the function lcd_data_write() add A  LOT more nops for testing. This is where another overclocking happens. The issue may also be with the display itself.

[tzenis]

The picture was taken with the clock configuration disabled.
At low speed, the MCU probably hangs, display remains white. Only two times I saw the grid on the display.
At high speed, the MCU probably resets, display remains black. The display blinks occasionally.
I will try tomorrow connect with the gdb.

[ataradov]

I would say hanging at the low clock speed is probably normal. There are a lot of things that are timing sensitive.

Partial picture like this is also normal, since it redraws  the screen column by column. So something is hanging in other tasks between redraws.

I would try to lower the overall clock instead of just disabling the configuration altogether. In the following part "(500 << RCU_PLL_PLLN_Pos)" replace 500 with 200 (for 100 MHz total clock). This will drop the clock way below the nominal. But at the same time it will maintain the timing relationship between all the clocks. So it should work, just at a lower overall clock.

[tzenis]

I tried with the lower clock speed as you suggested. It doesn't help.
I checked again the 20 MHz crystal. There are only single negative pulses (no oscillations) with a width of 26 us with a frequency of 610 Hz (picture in my first post).
I added delay_cycles(100000) before the line RCU->CTL_b.HXTALEN =1. The shape of pulses on the crystal remained the same. The frequency decreased to 127 Hz. The additional delay is 6.2 ms. Adding the same delay after the line RCU->CTL_b.HXTALEN = 1 doesn't change anything. The frequency should decrease to ca 57 Hz but remains on 127 Hz.
The MCU resets on the line RCU->CTL_b.HXTALEN = 1.
Could you point me a documentation for the registers of GD32F407, like RCU->CTL_b, RCU->PLL ? I didn't found. I found only datasheet without this information.

[tzenis]

I downloaded GD32F4xx_User_Manual_EN_Rev2.3.pdf
I disabled HXTAL and changed PLL to use internal 16 MHz RC. Now it can run also on 250 MHz. Not always it starts. It starts only 1 from 10 times of power on. Tested on 100, 200 and 250 MHz.
Issues:
- HXTAL doesn't work. I want check to use an external clock source instead of the crystal.
- The battery level meter time to time drops to zero level.
- Not always it starts with RC.

[ataradov]

If MCU resets when you enable the crystal, then something is really wrong. It may be some issue with soldering. Double check that you don't have any shorts.

So even the simplest code like this

Code: [Select]

  RCU->CTL_b.HXTALEN = 1;
  while (1);
constantly resets the MCU?

[tzenis]

After some time my scope become stable with the internal RC clock source.
I have a cold solder joint somewhere. The baseline jumps between two levels in AC mode.
I tried to start the crystal:
while (1); after RCU->CTL_b.HXTALEN = 1; works stable, I can see oscillations on the crystal.
while (1); after RCU->CTL_b.PLLEN = 1; works stable, ...
while (1); after RCU->CFG0 = ... works stable, ...

Full application: can (not always) run. MCU resets when I touch the crystal pins with a probe (1:10).

I go to search the cold solder joint.

Tibor

[thinkfat]

Is there a way to configure the drive strength of the internal amplifier for the oscillator, or a configuration to match a crystal with a different capacitive load requirement? I'd take a good look at the capacitors next to the crystal as well.

[ataradov]

No, there is only enable or disable.

And it should not be that sensitive to probing with x10 probe. Also, does it stall if you touch either pin (XIN/XOUT)? Or just some specific pin?

[tzenis]

My device is very unstable. One time it runs stable for few minutes. Other time can't start for few minutes.
I was able to see oscillation on the crystal during running application just now. I probe the crystal pads directly, not the pins of MCU.
I checked noise on capacitors located near the edges of the MCU. Everything looks fine.
I go to check MCU pads soldering by a needle under a microscope.

I already tried to touch any part/pins by a plastic tool without any effect.

Tibor

[ataradov]

I think you can't avoid more debugging. This is an unusual issue, so there is no readily available answer.

I would start with a simple firmware that just runs on the internal RC (default settings). Initialize only the LCD, but disable all the ADC and scope stuff. Just draw some random lines in the LCD or print some text (incrementing numbers, for example). Make sure that it runs in this configuration reliably even when you poke and touch the MCU.

Then switch to the PLL, still driven by the internal RC (keep the clock low, 100 MHz). Repeat the experiment.

And then switch to the crystal.

[tzenis]

It is very difficult to debug it. New issues occur, old ones disappear at random time...
I checked all pins of the MCU under microscope. I didn't found any problem. I re-soldered all pins one-by-one manually. After this, the MCU was able to run with crystal at 250 MHz.Unless I closed the back cover. After closing the cover, it was not able to start the crystal more. I changed clock to internal RC, 250 MHz. It runs...
The most recent issues:
- Spikes at 62 and 125 MHz rate, noise only; open or short input, baseline in middle. I think not all bits from the ADC are read in the time. The result is a mixture of bits from 0x7f and 0x80. Rate of the spikes depends on the CPU activity. Pressing the 1/10X button increases the rate little, trigger level button more. After shifting the baseline level, the spikes disappear. The spikes are not present always. Sometime immediately after power on, sometime after some time...
- "Flash error"; reading signature bytes failed. I saw this error today two times, never before.
- It doesn't switch off after sliding the switch to the off position. This issue started yesterday. At beginning it switched off after few seconds, today it stay on for more than 2 minutes. There can be a voltage from the pin PB1 / VBAT_SENSE, if the pin is in an incorrect state.

Tibor

[thinkfat]

I still think there's maybe an issue with the xtal oscillator itself. The crystal needs to meet certain specs so that the oscillator circuit inside the MCU can drive it properly. Maybe the crystal just marginally meets these specs and the changed MCU is a little different from the original? How did you exchange the MCU, did you hot-air the chip off? Maybe the crystal got roasted, maybe the load capacitors near the crystal are damaged or just not the optimal value.

PS: could be a mechanical issue with the PCB, hairline crack in a trace that makes it stop working if you close the case or mechanically stress the PCB when you press the buttons.

[tzenis]

I used to remove the old MCU a sharp knife to cut off pins from the MCU and a solder iron to remove pins from the board.
I can replace the crystal. I have here an old testing board with an atmega and 20 MHz crystal. It is not SMT but can fit.
I applied a mechanical stress to the scope board without any effect.

Tibor

[ataradov]

I don't see how the switch can not disable the device. The switch controls the enable pin of the LDOs. VBAT_SENSE takes a divided output of the LDO.

I would double check the primary supply voltage (battery) and the LDO outputs. Check that there are no weird oscillations or something like that.

Given the number of issues that should not be related to each other, I would have a very close look to the power supplies.

[tzenis]

I already checked the LDO, switch. There are no oscillations. It was measured in the situation when the switch is off and device is on.
The VBAT_SENSE can't be connected to a output of the LDO for sure.
The switch connects battery with a divider. Output of the divider is connected to the VBAT_SENSE pin and through a black component with a label S4 to the enable pin of the LDO. Voltage on both sides of the "S4" component is the same. If the VBAT_SENSE is an output, it can provide a power to the LDO enable.

I checked the MCU at 125 MHz. There were no spikes using both RC and hxtal. The spikes can depend on temperature of the MCU. At 250 MHz, the rate of the spikes increases with time, the temperature also increases. It was able to run on the crystal only a short time.
One time the stlink was able to flash full 32 kiB without printing error. But only one time.

[ataradov]

I just don't see how VBAT ADC pin can become an output. The device must be super messed up at that point.

So at 125 MHz it basically works fine? Or just the spikes go away and the reset is still broken sometimes?

As for the programming error, I do remember that my tools had issues too when device was running from the PLL. Hence there is while (1) loop if F2 is pressed on power-up. Other than this I never had any issues.

[tzenis]

I replaced the crystal. Nothing changed. It can't run using the crystal most of the time. No matter of the PLL speed.
It runs fine using the internal RC at any speed. The spikes are there only at the highest speed, 240 MHz is spike-less.
The problem with the power off disappeared yesterday. This problem was there also at lower speed.
Many problems come-in, come-out at random time.
A wrong level of the ground level of a part of the MCU can explain at least part of the problems, like unstable battery level measurements, a voltage on an input pin (over-voltage protection: pin o---|<|----| ground).
I will check the all ground pins of the MCU. One of the edge capacitors is connected to the pins VDD and NC (pins 72, 71).
The F2 helps with the programming, thanks.

Tibor

[ataradov]

The unconnected pin is actually connected on the original ST part. So this may explain why the capacitor is there.

It is possible that some parts are less stable, of course. All my parts (3 in the scopes, one on the breakout/prototyping board) came from the same batch and they seem to be doing fine.

Without F2 my devices refused to program almost always. No idea why, SWD connection just was not stable. Access to the reset pin would solve that, but we don't have it.

[tzenis]

Correction: the pins VDD and NC are 49, 50. I looked to a wrong package.

[tzenis]

I checked all the power pins of the MCU, everything looks good. On page 24 of gd32f407 datasheet, the pin 49 is a NC with the function: "Default: VCORE".
After touching the power pins, it was able to run with hxtal. The spikes were there at 250 MHz. I made many tests at 240 MHz, all OK. I tried to find the highest stable frequency and the power-on ends now with "Flash error". Sometime the bottom half of the screen contains a garbage at the highest speed. It is a "periodical" pattern with a different color, probably single bit mismatch. I don't have a photo of it. This MCU is not able to run at 250 MHz.
The "Flash error" is now permanent using both hxtal / internal RC PLL clock. I checked signals on the flash chip. CLK and DO signals looks strange (on both MCU and flash chips). I checked the DAC output located near the pins used for flash wiring. There is only very slow rise of voltage (T1/2 ca 10 s).

Tibor

[ataradov]

This looks like a short on the board, so signals have to fight with each other. But i have no idea why all the signals would be affected at the same time.

I think you need to make a simple program that toggles each pin on and off and have a look at them individually. May be start with the flash pins, since they are obviously affected.

[tzenis]

I checked a resistance between the flash CLK and DO pins. There was only 120/160 Ω (depending on polarity). I cleaned the space between these pads by a needle. It works now!
It seems it can work fine at 120 MHz. It is not a big drawback. I'll not replace the MCU for this issue.

Thanks!

Tibor

[ataradov]

It looks like your flux may be conductive or something, which would explain a lot of the issues. May be try to clean it better from the rest of the MCU.

The issue with running from the lower clock is that you will have to recalculate all the timings.

[GeorgeOfTheJungle]

It looks like your flux may be conductive or something, which would explain a lot of the issues. May be try to clean it better from the rest of the MCU.

Yep, that's what I suspect is happening. I've also had that problem once. Find something to dissolve the flux, and use a loupe and a toothbrush or something. Sometimes I wish there was a mini karcher for things like that.