Simple I2S app on STM32G0136-disco is failing

[Scott3]

I have created a simple app using stm32cubemx and cubeide that waits for a GPIO signal to go low, then plays a canned stream of I2S data to the port. The function call to HAL_I2S_Transmit() is causing the system to reset. Specifically the statement: __HAL_I2S_ENABLE(hi2s) causes the i2C output signals to transition into the active state, then the chip resets.

I've generated the init code with MX and get no compile errors or warnings. I've attached the project.

Thanks,

Scott

[waclawek.jan]

> Specifically the statement: __HAL_I2S_ENABLE(hi2s) causes the i2C output signals to transition into the active state

It's unlikely - that macro probably just sets I2SE in SPIx_I2SCFGR.

Single-step the code in disasm - does write to SPIx_I2SCFGR indeed cause I2C signals to go down?

Try to divide and rule - disable interrupts from I2S and see what happens.

I also assume there's nothing more in the code than I2C and I2S - if yes, remove it to achieve the bare minimum exhibiting the problem.

  

JW

PS. Please change your user name to a normal nick.

[Scott3]

Hi Jan,

Thanks for the reply. Yes, this code is running on the stm32g0136-disco board. But isn't MX supposed to generate workable code? Is there an interrupt assignment I am missing, even though I am using the polled calls?

Thanks,

Scott

[Scott3]

I thought perhaps there was an uninitialized interrupt vector, so I added __disable_irq() to my code after initialization. It didn't make any difference.

Even though "It's unlikely - that macro probably just sets I2SE in SPIx_I2SCFGR", single step tracing through that statement shows the reset handler with the IP set to mov sp,r0.

 .section .text.Reset_Handler

 .weak Reset_Handler

 .type Reset_Handler, %function

Reset_Handler:

 ldr  r0, =_estack

 mov  sp, r0         /* set stack pointer */

/* Copy the data segment initializers from flash to SRAM */

 movs r1, #0

 b LoopCopyDataInit

CopyDataInit:

 ldr r3, =_sidata

 ldr r3, [r3, r1]

 str r3, [r0, r1]

 adds r1, r1, #4

LoopCopyDataInit:

 ldr r0, =_sdata

 ldr r3, =_edata

 adds r2, r0, r1

 cmp r2, r3

 bcc CopyDataInit

 ldr r2, =_sbss

[waclawek.jan]

So, it goes into reset? Is anything external connected, or is this only the "pure" DISCO board? Can't the shared pins be in conflict with each other? How exactly are the relevant GPIO registers set just before that macro, as read out by the debugger?

JW

[Scott3]

Hi Jan,

It is a disco board that I have wired to an Atmel D21 Xplained Pro (as a source of I2C data) and a MAX98357A a speaker driver. I have the MX project configured only as a I2S master using pins 4, 5 & 6 and pins 7 & 8 for the debugger. Pin 1 is a GPIO input, so I don't think the reset function is enabled. I will check over the settings for the reset controller to see if it is enabled in spite of not being named as a reset input.

Thanks,

Scott

[waclawek.jan]

Scott,

I mean, two connected pins, bith turned to output with different polarities. That might have caused a reset through a power supply drop.

Disconnect the external device and try again.

JW

[Scott3]

Hi Jan,

With all pins disconnected, the CPU still resets at the __HAL_I2S_ENABLE(hi2s) macro.

Scott

[waclawek.jan]

The 8-pin package has several pins connected internally. Maybe these are in conflict.

How exactly are the GPIO registers set just before that macro, as read out by the debugger?

Read them out and check/post.

JW

[Scott3]

Hi Jan,

Here are the GPIO register values. All values not listed are zero. This is in hex integer format, so 0x80000000 is bit 31 set.

 50000000 EAFFFFFB 00000000 0C000000 24000000         

 50000010 00004002 00000000 00000000 00000000         

 50000400 FFFFFFFE 00000000 00000000 00000000         

 50000800 CC00F000 00000000 00000000 00000000         

 50000C00 000000FF 00000000 00000000 00000000         

Thanks,

Scott

[waclawek.jan]

Looks good.

How is FLASH_OPTR.NRST_MODE set?

JW