Thank you for your help.

I checked the points you raised and they were correct.

After many attempts and using the SS debugger as you recommended, I noticed that the problem was the connection of the P0.5 (RX) pin with the VCON interface, as it is always connected to the VCON and this was generating conflict with the CP2102 module :

 

 

The solution was to disable the VCON interface by grounding the VCON enable pin (P2.1):

 

After that it worked perfectly.

I suggest you take a look at the example F93x_SleepMode_PortMatchWake

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\8051\v4.1.7\examples\C8051F930DK\SleepMode\F93x_SleepMode_PortMatchWake

i guess you meant to place an array in the flash start @ specific address. 

This is a GUN/GCC general question,  there are several KBA that cover this topic : 

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2019/01/17/erroneous_ld_script-ZkdZ

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2016/03/08/using_a_linker_scrip-s5bu

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2018/06/27/how_to_locate_anent-Uyrh

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2018/07/03/how_do_i_set_thedeb-8o7a

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2016/03/08/using_a_linker_scrip-s5bu

 

 

Reading/writing to flash within your firmware application is discussed in section 6.3.11 Erase and Write Operations of the EFR32MG21 Reference Manual, and utilizes the Memory System Controller (MSC) peripheral. We have example code implementing the read/write functionality on our public GitHub repository located here - https://github.com/SiliconLabs/peripheral_examples/tree/master/series2/msc/msc_rw, which stores data to the UserData page. Additional information is also available at docs.silabs.com - https://docs.silabs.com/mcu/latest/efr32mg21/group-MSC 

It looks like there is a bug in pwr.c for the function PWR_readAndClearWakeFlags(), which I assume is what you are calling? This function sets the SFR page to 0 when, according to the EFM8BB3 Reference Manual, the SFR page for register PMU Status 0 should be 0x10. You can make this change in your SDK by changing line 28 (for 8051 SDK v4.2.0) from

SFRPAGE = 0;

to

SFRPAGE = 0x10;

I've created an internal ticket to fix this issue for future releases.

This case was handled with a support ticket, however, code optimization set the MCU breakpoint prior to PSTAT0 read/clear execution. Lowering the optimization level alleviates the issue. Should also be able to step further through the code to execute PWR_readAndClearWakeFlags() properly with higher optimization.

It looks like there is a bug in pwr.c for the function PWR_readAndClearWakeFlags(), which I assume is what you are calling? This function sets the SFR page to 0 when, according to the EFM8BB3 Reference Manual, the SFR page for register PMU Status 0 should be 0x10. You can make this change in your SDK by changing line 28 (for 8051 SDK v4.2.0) from

SFRPAGE = 0;

to

SFRPAGE = 0x10;

I've created an internal ticket to fix this issue for future releases.

Thanks for the answers. The thread can be marked as "answered". The design of the circuit ensures that current from the clamp diode never pulls  Vcc up.

Regards

Henner

 

plzz guide me

Which EFM32 device you are working on?

AFAIK the MOSI will keep the last bit state in idle. I am wondering if you could try to set the MOSI as open-drain (instead of push-pull) to see if it make any difference and still works.

Use the internal or external pull-up to set the MOSI high to meet the requirement from slave.