IDW01M1 Wifi Sample Codes for STM32F411RE

Hi Mridu,

And I set more breakpoints to see when the ring buffer got to have the elements filled in

and I found that it's only when the program is running into the wifi_reset() but it would not come out of the wifi_reset() because it is trapped in the while() loop inside the wifi_reset().

Hope that you will have better idea on where to debug next...

Thanks & Best Regards,

Robert

Hi Mridu,

I set breakpoint inside the beginning of 1. Process_Wind_Indication(uint8_t *process_buff_ptr) in file wifi_module_uart_01.c

and it doesn't get hit at all.

Then, so is 2.!

So what strange point are you thinking of please?

Thanks & Best Regards,

Robert

And I checked the .map file ok with these 2 functions:-

 .text.Process_Wind_Indication

.text.Process_DeQed_Wind_Indication

Thanks & BR,

Robert

Surprisingly, if I set the breakpoints to one level higher of these 2 functions where they would be called,

1. Process_Buffer() would not be triggered with the breakpoint for Process_Wind_Indication()

2. Wifi_TIM_Handler() would be triggered even though the Process_DeQed_Wind_Indication() would not be triggered.

So it seems that timer itself may be ok but not the Process_Buffer()?!

Thanks & Best Regards,

Robert

It seems that Wifi_SysTick_Isr() cannot be triggered and then so Process_Wifi() and then so Process_Buffer()

but I don't know why Wifi_SysTick_Isr() cannot be triggered though...

Thanks & BR,

Robert

Looking a bit deeper, I found that it's related to the SysTick_Handler() in the startup_stm32f411xe.s of sample codes

but I am using the mbed one which would be generated differently as startup_stm32f411xe.o in the mbed folder.

And this startup_stm32f411xe.o would not cover the SysTick_Handler() at all!!

Not sure if I can replace this one from mbed one or not?!

Any idea please?

Thanks & BR,

Robert

Hi Mridu,

I tried different combinations of mbed files and the original Server_Socket files

but without much success.

1. In my previous builds, I didn't use the syscalls.c from Server_Socket sample but retarget.c from mbed.

    However, if I tried to use ./Projects/Multi/Applications/Server_Socket/SW4STM32/STM32F411RE-Nucleo/syscalls.o

    I would not be able to compile at all, so I have to stay with

    $(MBED_PATH)/$(TARGET_BOARD)/TOOLCHAIN_GCC_ARM/retarget.o 

So in my Makefile, I use all the other files from the Server_Socket sample except the syscalls.c:-

./Drivers/BSP/STM32F4xx-Nucleo/stm32f4xx_nucleo.o \

2. My latest build would not trigger the Wifi_TIM_Handler() as I reported yesterday after all the different trials.

    Since I didn't really modify any C codes, the only things I played around were the Makefile and the LinkerScript.ld.

    So I suspect that I made some wrong change in the LinkerScript.ld?!

    In fact, I use the one from mbed as the base:-

    LINKER_SCRIPT = $(MBED_PATH)/$(TARGET_BOARD)/TOOLCHAIN_GCC_ARM/$(TARGET_LD).ld

    and so some potential conflict with the files from Server_Socket sample?!

Therefore, I am clueless now...

Thanks & Best Regards,

Robert

Hello!

I would like to ask if the SysTick_Handler in the isr_vector never gets triggered in my program,

how can I see if the interrupt flag is enabled correctly or not under Eclipse IDE / OpenOCD debug environment please?

Thanks & Best Regards,

Robert

Thanks Jerry!

I found from the Cortex-M4 reference manual that

0xE000E010 STCSR SysTick Control and Status Register

0xE000E014 STRVR SysTick Reload Value Register

For the pure Socket Server sample app,

these two registers would have the values:-

0xE000E010 STCSR SysTick Control and Status Register  0x07000100

0xE000E014 STRVR SysTick Reload Value Register          0x1F480100

after wifi_init()

However, for my mixed mbed build,

I will have 0x0 only.

However, when I forced these two registers to have the same values,

0xE000E010 STCSR SysTick Control and Status Register  would take only 0x07000000

and the initialization will then be completed ok with the printf().

And SysTick Control and Status Register  would become 0x07000100 eventually as well.

Therefore, it seems that somehow my mixed mbed HAL drivers or the linkerScript.ld will make the SysTick initialization failed?!

However, I have no idea on how to debug this further.

Any suggestion please?

Thanks & Best Regards,

Robert

Hello!

I observed another weird behavior when I tried to find out when the SYSTICK CTRL register would be set.

In the original Server Socket sample app,

I can step into the HAL_InitTick() and then I will go to the HAL_SYSTICK_Config() inside the core_cm4.h.

However, in my mixed build,

it would not get into any HAL_SYSTICK_Config() when I tried to step into the HAL_InitTick()

and similar problem to the following HAL_MspInit() too.

But when I checked the .map file, I can see:

.text.HAL_SYSTICK_Config

while in the .map file of the original sample app:-

.text.HAL_SYSTICK_Config

So it seems that the mbed's stem32f4xx_hal_cortex.o is different from the sample app's...?!

Thanks & BR,

Robert