2014-12-11 11:07 AM
Setup:
I used CubeMX to generate and added code to blink 2 leds and compiled with IAR Embedded. LEDs are connected to PB3 and PB5. I have several boards I soldered 042's to with proper caps, and leds with current resisters. Issues: STM32F042K6's soldered to QFP to DIP adapter boards and plugged into breadboards work as expected. Chips soldered to a custom carrier board work 'sometimes.' If my thumb is over the chip and touching most pins, then code runs good. (Thumb only needed to START code running from reset...) All STM32F042K6 chips and caps are from same lots. Any ideas on what I am missing? Seems like it could be clock related, but I am using internal clock. PF0 and PF1 are wired to a header with 2,2K pullup resisters to 3V3. Dan #stm32f042k6 #problem-solved2014-12-11 11:48 AM
Any ideas on what I am missing?
Proper soldering ? Do you have sufficient buffer caps, near the MCU, and in proper orientation ? (easy to place the wrong way ...)
2014-12-11 12:44 PM
Thanks for the fast reply!
I have removed and soldered NEW chips to board and after programming issues are the same. Taking the chips I removed from custom board and soldering them to the QFP to DIP boards results in properly working designs. All CAPs are non-polarized, so there shouldn't be issues there. They are placed closer to the MPUs on the custom boards than when used with the adapters, and batchs are all the same. Any other ideas?2014-12-11 01:24 PM
Well much more probable supplies over clocks.
Make sure you've got all your supply pins hooked up, even the analogue ones. The analogue ones have the power on reset circuitry. Check the state of NRESET, and BOOT0 pins. Not clear from the description if the parts not running, or your codes not running. I'd opt for something really simple that didn't require the clocks and PLLs turning on. Other than that you might want to share a schematic, or portion thereof2014-12-11 02:05 PM
Code inserted into generated CubeMX output is:
/* USER CODE BEGIN 3 */
/* Infinite loop */
while (1)
{
//HAL_IWDG_Refresh(&hiwdg);
for(u32Delay=0;u32Delay<0xFFFF;u32Delay++);
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_3, 0);
for(u32Delay=0;u32Delay<0xFFFF;u32Delay++);
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_3, 1);
for(u32Delay=0;u32Delay<0xFFFF;u32Delay++);
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_5, 0);
for(u32Delay=0;u32Delay<0xFFFF;u32Delay++);
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_5, 1);
}
/* USER CODE END 3 */
2014-12-11 03:42 PM
Yes, would like to see a pull-up resistor on the NRST pin (it's an open-collector driver) so that it has some chance of going high as it charges, and a pull-down on BOOT0
2014-12-12 04:57 AM
Pg 82 of the datasheet says there is an Permenant Pullup on the nreset pin. Also, I have monitored the voltage across the cap I have installed there and it takes about a second to reach 3V3. Looking into the BOOT0 pin now.
2014-12-12 05:14 AM
Turns out that the PullDown for BOOT0 was the problem. Of course I neglected to bring the pin out to a pad or anything... $40 and that is solved.
Thank you Clive for your help with this issue. It was driving me up the wall! Dan2014-12-12 05:31 AM
Pg 82 of the datasheet says there is an Permanent Pullup on the nreset pin.
Yes, but it's not very strong. RC reset circuits are notoriously awful design choices for power-on-reset.2014-12-12 06:29 AM
Is there a better way to do reset? My first revision of this board use an STM809SWX6F MPU Reset Circuit, but I couldn't program via SWD due to it being stronger than the programmer on the reset line.
I'm all for finding a better way!