STM32F334 Programm doen't start withoput manual reset

[eg7963]

Posted on December 12, 2016 at 09:49

Hi there,

I have a set of 3 pcb's that i am testing I have written a programm that used to work on a previous versionof the pcb, and there have been minor changes between the 2 Version.

The problem is that when i run the programm into debug mode ( ulink pro), the program runs fine on all three of them.

8

However, when i start the pcb in normal mode (i.a mcu is started without debugger, just when powering up the 3,3V on the input), only 1 of the 3 pcbs works, the other 2 not running (a led starts to blink when the program runs). Only a manual reset on the reset pin helps to start the program.

The reset pin is linked to an external pull up resistor of 15k and a capacitor of 100nf ( as advisedin the datasheet )

Rising time of the 3,3V is 2-3us , rising time on the Reset pin is in the few milliseconds domain.

We use all the recommanded capcitors on the VDD and VDDA pins , tied BOOT0 to GND, and use an external clock source of 24MHz (the instruction clock is then set to 74MHz, which is the max value admissible by the Device)

We use a Goldcap on the BAT input, that provides

Here are the things i tested so far:

- increasing and reducing the input cacpacitance on the reset pin to play with the rising time - FAIL

- reducing the pull up resistor - FAIL

- Check the soldering of the crystal oscillator, and the signals comming into OSC Input, the 24MHz looked good, so it was a FAIL again to solve hte problem.

- using the internal oscillator of 8 MHz - FAIL

Has anyone experienced such type of problems in the past , and iff yes , is there a solution to resolve it?

Thanks in advance for any help brought.

Eric

#adc #can #cubemx #stm32f334

[Manu Abraham]

Posted on January 30, 2017 at 17:14

Hi,

Simply remove the pullup resistor on NRST and it ahould be good to go

[eg7963]

Posted on January 31, 2017 at 09:21

Hi there,

Thx for the answer. I solved my problem a while ago already. The pull up on the NRST is fine and didn't cause the problem.

For some reason the problem came from the code generated through the stmCubeMX. the device did not hang itself up but was instead going into error state right during the init phase. I discovered that right after implementing an error handling routine in the program, making blink LEDS to know from where the problem was coming.

The CAN Init routine generated by STMCubeMx was the culprits. What happened is that i regenerated my init code with stmCubeMx with an updated version of the Cube without allowing the project to be updated.This also generated a double SysclockInit that was also leading to an error.

After updating the project itself, the code run smooth ... for a little while...until i did a new update of the cortex M4 definitions. That led to the same the problem again, always in the CAN Init routine, that generates an error into the initialisation code, a reset fixes it. As i dont need CAN right now, i deactivated it and the program init runs smooth again.

I encountered another problem into the ADC init routine, on a chip where i use only one ADC, the mode is initialised as Reserved (0x04) while it should be initialised aas ADC_MODE_INDEPENDENT, causing an error into the adc, that then doesn't start. Thus everytime i regenerate the code , i have to add the 'multimode.Mode = ADC_MODE_INDEPENDENT;' in the init code generated in order to get ADc to work right.

[Amel NASRI]

Posted on January 31, 2017 at 11:09

Hi

Goeppert.Eric

‌,

Thanks for the follow-up of this discussion and the helpful update you provided.

I'll mark this question as assumed answered but I am interested to know if initially reported issues are still being faced with last CubeMX 4.19 version.

If yes, it will be interesting to make an update with current status for both CAN & ADC related issues.

-Amel

[stm32cube-t]

Posted on February 03, 2017 at 16:34

Hello Eric,

The ADC issue will be fixed in STM32CubeMX next 4.20.0 release.

Best regards