Profile

JohnB

Profile Data

Screen Name: JohnB

Screen Name*

Title

First Name

Address:

Last Name

URL (i.e. Company, Github, LinkedIn)

Email

LinkedIn account

Company

Phone number

Country

Bio

Indicates required field*

My Activities
Following

Member	Action	Date
JohnB	Voted up em3_is_just_em2_deepsleepwithsoftwareememu-aAX6 Show more	6 days ago
JohnB	Selected an answer for Unexpected LETIMER start delay Hi Vld, You graphic was quite helpful. The problem you're seeing is that you are issuing three writes to the LETIMER registers. Any write into logic that runs in one of the LFxCLK domains takes 3 HFLE clock cycles plus one LFxCLK cycle to propagate. Because the LFxCLK domains are asynchronous to the HFLE domain in which the registers operate, there is the potential for up to one LFxCLK clock of additional delay during synchronization. So, the fact that you are seeing 60 - 80 µs of delay makes sense. We would expect the the CPU core will post these writes and not stall waiting for them to complete. So, some of the delay seen is the fixed delay associated with the register writes in the HFLE domain. If you are running at a frequency greater than 32 MHz and use the default prescaler for the HFLE clock (divide-by-2), each LETIMER register write — and I mean just the register write, not the propagation time into the LFACLK domain — takes 7 HFBUSCLK cycles (3 HFCLKLE cycles x 2 + 1 wait HFBUSCLK cycle) = 0.175 µs (assuming the HFCLK = 40 MHz). That's not too long in the scheme of things. Where the delays really start to kick in is with all of the synchronization of signals going into and coming out of the LFACLK domain. So, the write to LETIMER->CMD to start the timer is going to take 1 LFACLK plus synchronization time. Likewise, the timer from the underflow event occurring to when it is actually propagated by the LETIMER IRQ logic to the NVIC is going to be another 1 LFACLK plus synchronization. These delays together account for the slack you are seeing between when you think you actually started the LETIMER to when the actual LETIMER IRQ handler is executed. In short, if you want more immediate, synchronized timing use one of the TIMER or WTIMER modules; do not use the LETIMER (or the RTCC or the CRYOTIMER, for that matter). The LETIMER's benefit lies in its ability to run in EM2. It is not a high-frequency timer and should not be expected to operate like one. Regards, John Show more	8 days ago
JohnB	Replied to Unexpected LETIMER start delay Hi Vld, You graphic was quite helpful. The problem you're seeing is that you are issuing three writes to the LETIMER registers. Any write into logic that runs in one of the LFxCLK domains takes 3 HFLE clock cycles plus one LFxCLK cycle to propagate. Because the LFxCLK domains are asynchronous to the HFLE domain in which the registers operate, there is the potential for up to one LFxCLK clock of additional delay during synchronization. So, the fact that you are seeing 60 - 80 µs of delay makes sense. We would expect the the CPU core will post these writes and not stall waiting for them to complete. So, some of the delay seen is the fixed delay associated with the register writes in the HFLE domain. If you are running at a frequency greater than 32 MHz and use the default prescaler for the HFLE clock (divide-by-2), each LETIMER register write — and I mean just the register write, not the propagation time into the LFACLK domain — takes 7 HFBUSCLK cycles (3 HFCLKLE cycles x 2 + 1 wait HFBUSCLK cycle) = 0.175 µs (assuming the HFCLK = 40 MHz). That's not too long in the scheme of things. Where the delays really start to kick in is with all of the synchronization of signals going into and coming out of the LFACLK domain. So, the write to LETIMER->CMD to start the timer is going to take 1 LFACLK plus synchronization time. Likewise, the timer from the underflow event occurring to when it is actually propagated by the LETIMER IRQ logic to the NVIC is going to be another 1 LFACLK plus synchronization. These delays together account for the slack you are seeing between when you think you actually started the LETIMER to when the actual LETIMER IRQ handler is executed. In short, if you want more immediate, synchronized timing use one of the TIMER or WTIMER modules; do not use the LETIMER (or the RTCC or the CRYOTIMER, for that matter). The LETIMER's benefit lies in its ability to run in EM2. It is not a high-frequency timer and should not be expected to operate like one. Regards, John Show more	8 days ago
JohnB	Selected an answer for stm32f4 as USB-host for CP210x Hi Charli, We do not support use of CP210x devices with on microcontrollers like the STM32F4. In essence, you need a USB host that can run Windows, Mac OS X, or Linux. In theory, if you have the right board, you could run uClinux on the STM32F4, although we have never tried or tested that. Alternatively, if you are inclined to write your own device driver, you can view the source code for the Linux driver here... https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/usb/serial/cp210x.c?h=v5.7.5 ...in conjunction with the API documentation lweiguo mentioned. If you need something in a pinch, I'd suggest passing on the STM32F4 and going with a Raspberry Pi. For the minimal investment, you'll have a small device that can instantly communicate with the CP210x. This, of course, you know the protocol the walkie-talkie is expecting on its end... John Show more	10 days ago
JohnB	Replied to stm32f4 as USB-host for CP210x Hi Charli, We do not support use of CP210x devices with on microcontrollers like the STM32F4. In essence, you need a USB host that can run Windows, Mac OS X, or Linux. In theory, if you have the right board, you could run uClinux on the STM32F4, although we have never tried or tested that. Alternatively, if you are inclined to write your own device driver, you can view the source code for the Linux driver here... https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/usb/serial/cp210x.c?h=v5.7.5 ...in conjunction with the API documentation lweiguo mentioned. If you need something in a pinch, I'd suggest passing on the STM32F4 and going with a Raspberry Pi. For the minimal investment, you'll have a small device that can instantly communicate with the CP210x. This, of course, you know the protocol the walkie-talkie is expecting on its end... John Show more	10 days ago
JohnB	Replied to Layout - ok to route traces underneath EFM32 (EFM32HG QFP48 package)? Hi Joshua, I would prefer that you keep the 3V3 trace as far away from the USB pins as possible to avoid the risk of coupling digital supply noise into the USB D+/D- pins. RESETn is effectively static, so its placement would be less of a concern, and you can always put a small capacitor (no more than 100 nF) on it, if need be. Our general concern with routing traces underneath the package is that if you are using a crystal, the noise from your traces can couple into the oscillator and cause problems with crystal start-up and stability. You're not using a crystal, so the 3V3 trace being near D+/D- would be the only other concern. John Show more	23 days ago
JohnB	Voted up excellent_-_was_the-gz1W Show more	Apr 22 2020, 12:39 AM
JohnB	Unselected an answer for EFM32TG110 IO Retention in EM4 EMU_EM4CTRL is used to enter EM4 mode. To retain the GPIO state, you could take a look at section 28.3.3 of the reference manual. Show more	Apr 07 2020, 6:54 PM
JohnB	Replied to EFR32FG12 Production Tool to flash custom bootloader, main program and perform self tests Hi David, Because you are using a WSTK mainboard as your debug interface, you can probably recover the bricked boards using: `commander device recover` This invokes a firmware routine in the board controller that issues the necessary set of SWD commands to access the AAP and issue a device erase command. Device erase should recover your boards, barring unusual circumstances. Note that device erase is not the same as mass erase. You can only issue device erase via the AAP. As far as using C# to code this process, we don't have any particular recommendation or examples for that. We tend to use Python for such things at Silicon Labs. One initial concern I have in looking at what you've done is why are you programming a binary image into the device and not a hex file? A binary image has no address context, and there is always a slim possibility you've got a bad pointer potentially generating data in a portion of the memory map you don't want to touch. Converting that hex file to a binary might produce an image that does not program into the device correctly. John Show more	Apr 01 2020, 2:29 PM
JohnB	Selected an answer for SDCC instead of Keil 8051 There's probably a way to run SDCC in Studio since it's built on Eclipse, and we've obviously bolted in GCC and IAR for 32-bit and Keil for 8-bit. However, no one on the applications engineering team has done this, so we're in the same boat as you. We are, of course, interested to see what you do to make it work should you decide to tackle it. Otherwise, we are kind of wedded to Keil, so figuring a way to support SDCC is not really in our plans. If you haven't already posted this in the Simplicity Studio forum, you might want to. The Studio team might have some pointers on this front. John Show more	Mar 16 2020, 6:03 PM

Level 7

Level 6

Level 5

Following 0

Followers 2