Errors in interfacing SX-SDMAH with stm32u575

Software
1

Hi everyone,

I’ve encountered a problem regarding errors messages from MM chip. My setup consists in a SX-SDMAH module and an stm32u575.

I have those messages of error:
E 6695 morse_pageset_write failed to write page: -32768
E 6695 morse_pageset_tx could not write 1 pkts - rc=-32768 items=1 pages=16
These messages occur after my system is successfully connected with the evk from silex.
(After the messages:

“WLAN STA connected
Link is up. Time: 68518 ms, IP: 192.168.200.2, Netmask: 255.255.255.0, Gateway: 0.0.0.0”)

My goal is to send packets to the other node of my network but it seems that it isn’t working.

Any suggestions?

Thanks in advance,

Mark

2

Hi @mark

This error could be caused by a number of reasons. Do the errors get worse or more frequent when you try to send traffic?

A common pitfall is improperly configured power save gpios. As an experiment, could you try disabling power save with mmwlan_set_power_save_mode(MMWLAN_PS_DISABLED) after mmwlan_boot?

3

Thanks @ajudge!

This is intersting. I disabled power save with mwlan_set_power_save_mode(MMWLAN_PS_DISABLED), and it works! The problem seemed to be solved.

Afterwords, I tried to connect the MCU and the SX-SDMAH to the main board with a flexible pcb (see attached figure)

Picture
Picture3608×2018 80.7 KB

If I use the flexible pcb to connect the two board, the same errors as above come up.

Any other ideas?

Thanks, mark

4

I also have another question… is there a list of possible error and their explanation?
I’ve encountered Transport Init Failed, Morse Chip Reset Unsuccessful.

Thanks in advance,

Mark

5

Not for any more detail than these error messages are providing. Though that is something I will raise with the team!

Those particular errors mean that the host processor (stm32u575) was not able to communicate with the chip during initialisation. This can be caused by a number of reasons - and I would recommend running the porting_assistant example to verify your hardware and hal implementations are correct.

Well that’s a good sign! And it might point to a hardware or software configuration issue on the BUSY or WAKE lines.

If the same errors start to then occur when a long cable is attached - this may point to signal integrity issues or “floating” GPIO states where there should be pullups. Logic analyzer traces tend to be very helpful at this point in identifying issues with initialisation.

If possible, can you share schematics (or a snippet), and your GPIO pin configuration for the STM32U575 (eg your cube.ioc file if using STM32Cube or MM-IoT-SDK)?