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.

I still could not catch your point.

a. Personally I don't think 'floating mode' is a good word here.

b. My personal understanding is that usually 'float' means the pin is not connected to anything.

I don't have time to study the ETA4056 deeply.

a. for ETA4056, when the EFM32LG configure the PE12 as disabled (or input), ETA4056 could regard the ISET as connect to nothing (floating).

b. when EFM23LG set PE12 as disabled,  the resistance is very high.

Please let us know if you have other question.

Are you using any other interrupts within your application? Interrupts only have two priority settings - high and low, and are low by default. If two interrupts are recognized simultaneously and both interrupts have the same priority level, a fixed order is used to arbitrate based on the interrupt source's location in the interrupt vector table and displayed in Table 6.1 of the EFM8BB1 Reference Manual -  

External interrupts and Timer0/1 overflows would take precedence over UART0 interrupts. Even so, UART0 has an 8-bit receive latch register, so a single acknowledge byte from the host, if being received correctly, should be available even if another interrupt was handled first.

Have you tried observing the UART0 RX bus with an analog oscilloscope when you believe there is a missing acknowledgement? How have you verified that an acknowledgement byte is being sent? There may be clues in this data capture as to why it's not being recognized.

Also, our 8-bit SDK has a UART0 Interrupt Example that is probably a better resource (more up-to-date) for the EFM8BB1 than application note AN115, and is available through Simplicity Studio via the Launcher perspective under "Software Examples".

Are you using any other interrupts within your application? Interrupts only have two priority settings - high and low, and are low by default. If two interrupts are recognized simultaneously and both interrupts have the same priority level, a fixed order is used to arbitrate based on the interrupt source's location in the interrupt vector table and displayed in Table 6.1 of the EFM8BB1 Reference Manual -  

External interrupts and Timer0/1 overflows would take precedence over UART0 interrupts. Even so, UART0 has an 8-bit receive latch register, so a single acknowledge byte from the host, if being received correctly, should be available even if another interrupt was handled first.

Have you tried observing the UART0 RX bus with an analog oscilloscope when you believe there is a missing acknowledgement? How have you verified that an acknowledgement byte is being sent? There may be clues in this data capture as to why it's not being recognized.

Also, our 8-bit SDK has a UART0 Interrupt Example that is probably a better resource (more up-to-date) for the EFM8BB1 than application note AN115, and is available through Simplicity Studio via the Launcher perspective under "Software Examples".

Are you using any other interrupts within your application? Interrupts only have two priority settings - high and low, and are low by default. If two interrupts are recognized simultaneously and both interrupts have the same priority level, a fixed order is used to arbitrate based on the interrupt source's location in the interrupt vector table and displayed in Table 6.1 of the EFM8BB1 Reference Manual -  

External interrupts and Timer0/1 overflows would take precedence over UART0 interrupts. Even so, UART0 has an 8-bit receive latch register, so a single acknowledge byte from the host, if being received correctly, should be available even if another interrupt was handled first.

Have you tried observing the UART0 RX bus with an analog oscilloscope when you believe there is a missing acknowledgement? How have you verified that an acknowledgement byte is being sent? There may be clues in this data capture as to why it's not being recognized.

Also, our 8-bit SDK has a UART0 Interrupt Example that is probably a better resource (more up-to-date) for the EFM8BB1 than application note AN115, and is available through Simplicity Studio via the Launcher perspective under "Software Examples".

Hi Alain,

Ubuntu 20.10 has the community-developed CP210x driver (cp210x.c). You should not have any need to "install" our driver because it is already there.

Furthermore, udev should recognize the device either when you boot or upon a hot plug event and load the driver for you.

You should not be downloading and otherwise building the driver from our web site. This is provided for customers who need CP210x GPIO support that uses ioctls, which is what we implemented very early in the product's life cycle. Since then, the Linux kernel has migrated from ioctl GPIO support to /dev/gpiochip, and the community-developed CP210x driver supports this.

Regards,

John

HI can somebody please help because i cant find solution for ncp messaging target -> host. 

I want to send from ncp-target( thunderboard) to PC host app just simple "hello" without that PC host needs to answer on that message.

Also can you say from where MCU target get info for Bluetooth stack and device address that it send to PC host app when it get from PC host app "sl_bt_system_get_identity_address()" 

Answer on that event is parsed in PC host and looks as:

"Bluetooth stack booted: v3.1.0-b178
Bluetooth public device address: 58:8E:81:A5:42:10"

Have you worked through the various steps outlined in our USB Debug Adapter troubleshooting knowledge-based article?

https://www.silabs.com/community/interface/knowledge-base.entry.html/2010/08/20/usb_debug_adaptertr-xshn

What device are you currently developing with, and are you developing with one of our starter kits or is this a custom PCB?

Hi Dexter,

The EFR32BG is most likely not ACKing because the device is sleeping in EM2/3 mode, but the I2C needs to be in EM1 mode in order to function. Every time the I2C peripheral on the secondary device is expected to function, you need to tell the Power Manager that the device needs to remain in EM1. After the I2C transaction is finished, either due to an error or a STOP bit, you need to tell the Power Manager that the device no longer needs to be in EM1. You can implement this by using Power Manager Requirements. You will need to add/remove EM1 requirement to the ISR like this:

void I2C0_IRQHandler(void)
{
    uint32_t flags = I2C0->IF;

    if (flags & (I2C_IF_BUSERR | I2C_IF_ARBLOST))
    {
        sl_power_manager_remove_em_requirement(SL_POWER_MANAGER_EM1);
    }
    else
    {
        if (flags & I2C_IF_ADDR)
        {
            sl_power_manager_add_em_requirement(SL_POWER_MANAGER_EM1);
        }
        else if (flags & I2C_IF_RXDATAV)
        {
            // etc 
            //i2c_buf[i2c_idx++] = I2C0->RXDATA;
        }

        if (flags & I2C_IF_SSTOP)
        {
            sl_bt_external_signal(flags);
            sl_power_manager_remove_em_requirement(SL_POWER_MANAGER_EM1);
        }
    }

    I2C_IntClear(I2C0, flags);
}

For more information regarding Power Manager, please view this page: https://docs.silabs.com/gecko-platform/latest/service/power_manager/overview

Regards,
Dayoung