cancel
Showing results for 
Search instead for 
Did you mean: 

STM32G4 - Program brand new MCU over SPI bootloader.

fw_guy
Associate II

I am seeing this issue on around 20% of new MCU's.

I am programming brand new STM32G474's through the internal bootloader over SPI. When put into bootloader mode, 20% of the MCU's wont respond with the synchronisation byte. I have played around with timings to no luck.

The peculiar thing is that if I program the MCU's with an ST-Link, the bootloader over SPI will then work/respond from here on. I'd like to avoid using the ST-Link and get to the bottom of why some of the chips don't respond when unprogrammed.

Should the bootloader work for brand new unprogrammed MCU's? To me it looks like that when the are programmed via ST-link, the pins are in a different state on startup which makes the bootloader work.

Any ideas what could be happening?

fw_guy

1 ACCEPTED SOLUTION

Accepted Solutions
fw_guy
Associate II

So, I finally got to the bottom of the issue. My ACK processing was wrong, on most MCU's the synchronisation byte is sent immediately, on some MCU's it comes after a few tries. In the later scenario I continued on before receiving the proper ACK.

Its working now for all my boards. Thanks for the help.

View solution in original post

5 REPLIES 5
TDK
Guru

They should all behave the same. Check option bytes relevant for boot modes, double check connections. Verify signal is being sent on a scope, verify power on chip, vcap voltages, etc.

If you feel a post has answered your question, please click "Accept as Solution".
fw_guy
Associate II

So, I finally got to the bottom of the issue. My ACK processing was wrong, on most MCU's the synchronisation byte is sent immediately, on some MCU's it comes after a few tries. In the later scenario I continued on before receiving the proper ACK.

Its working now for all my boards. Thanks for the help.

What exactly you've changed? would you please share the sequence?

fw_guy
Associate II

My original wait_for_ack function jumped out too soon and assumed everything was OK. This works now.

/** Waits for an ACK from the STM32 Bootloader before continuing with further messages
* @PAram[in]		timeout - duration to wait for an ACK
* @PAram[out]		None	
* @return			true if ACK received, otherwise false
*/
static bool wait_for_ack(uint32_t timeout)
{
	uint8_t resp;
	uint8_t dummy = 0x00U;
	uint8_t ack = BL_ACK;
	bl_stm32_wait_tmr_ms = 0;
	bool ack_received = false;

	spi_Transmit(&dummy, 1U);
	while(ack_received != true  && (bl_stm32_wait_tmr_ms <= timeout))
	{
		spi_TransmitReceive(&dummy, &resp, 1U);
		if(resp == BL_ACK)
		{
			/* Received ACK: send ACK */
			spi_Transmit(&ack, 1U);
			ack_received = true;

		}
		else if (resp == BL_NAK)
		{
			/* Received NACK */
			return false;
		}
		else
		{
			/* Received junk */
		}
	}

	return ack_received;
}

  

thanks, I'm following the same but there is no ACK