Member | Action | Date |
---|---|---|
![]() |
Selected an answer for
EFM32 Gecko STK SPI MOSI idle high
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.
|
2 hours ago |
![]() |
Selected an answer for
how to config a GPIO pin to floating status
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.
|
2 hours ago |
![]() |
Replied
to
EFM8 Interrupt priority
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". |
2 days ago |
![]() |
Updated
to
EFM8 Interrupt priority
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". |
2 days ago |
![]() |
Updated
to
EFM8 Interrupt priority
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". |
2 days ago |
![]() |
Selected an answer for
cp210x installing on ubuntu 20.10
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 |
5 days ago |
![]() |
Replied
to
[URGENT] - 8-bit USB debug adapter NOT USABLE
We recently had a customer do a Windows update and encountered some connectivity issues. Please try uninstalling the USB debug adapter driver then reinstalling. For reference, the debug driver for Keil uVision is available here - https://www.silabs.com/developers/8-bit-8051-microcontroller-software-studio
Show more
|
5 days ago |
![]() |
Posted
NCP messaging on
qna
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 |
5 days ago |
![]() |
Replied
to
[URGENT] - 8-bit USB debug adapter NOT USABLE
Have you worked through the various steps outlined in our USB Debug Adapter troubleshooting knowledge-based article? What device are you currently developing with, and are you developing with one of our starter kits or is this a custom PCB? |
6 days ago |
![]() |
Selected an answer for
EFR32 I2C slave + sleep wakeup data nacks
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:
For more information regarding Power Manager, please view this page: https://docs.silabs.com/gecko-platform/latest/service/power_manager/overview Regards, |
6 days ago |