Thanks for the assemble example jmg.

Please note that this thread continues here:

https://www.silabs.com/community/mcu/8-bit/forum.topic.html/efm8bb1_low_costkit-ledturnonoffpart2-Leb4

Hi Jason,

Thank you for your inquiry about using the EFM32HG LEUART.  I have a couple comments:

1) You may have forgotten to attach your code.  Please attach your LEUART code that you mentioned.

2) Please refer to our LEUART examples in our GitHub peripheral_examples repository for examples of how to configure and operate the LEUART:

https://github.com/SiliconLabs/peripheral_examples/tree/master/series0/letimer

3) You mentioned two data packets in your post - one with 8 bytes of data ("abcdefgh") and one with 9 bytes of data ("123456789").You said "third data is missing every time."  By tis do you mean there is a third data packet?  What is the length of the third data packet?

4) What device is sending this data to the EFM32HG device?  Can you see the data on the transmission line with a scope or logic analyzer, and it is just not received properly in the EFM32HG LEUART?

Thank you for providing additional information and checking te resources and examples we provide.

Regards,

Mitch

Hi Oleg Shi,

I have another suggestion as well.  Have the phone “forget” the device and then see if it will connect from that phone again. Or try connecting from a completely different phone.  Thanks, and please let me know if you have any questions.

Regards,

Mitch

Hi Oleg Shi,

Thank you for your inquiry about this failure of the OTA upgrade process for your BGX13P device.  I have a couple questions and comments to help get started troubleshooting this problem:

1) What firmware version were you running and what versions were you trying to update to?

2) Have you looked at the Bluetooth Xpress documentation on docs.silabs.com?  I especially recommend having a look at the firmware update section and the frequenctly asked questions to see if any information there can help you:

https://docs.silabs.com/gecko-os/1/bgx/latest/firmware-update

https://docs.silabs.com/gecko-os/1/bgx/latest/faq

I am continuing to look into this and will let you know if I have any new information for you.  Thanks!

Regards,

Mitch

Hi VI Merenkov,

Thank you for inquiring about the C8051F120 JTAG access procedures.  There is some description of the JTAG access for this device using the JTAG Instruction Register and Data Register in the C8051F12x-13x Datasheet/Manual in section 25, beginning on page 341.

This section also states "Access of the JTAG Instruction Register (IR) and Data Registers (DR) are as described in the Test Access Port and Operation of the IEEE 1149.1 specification."  I found the following link to a copy of this standard: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6515989.

I hope this helps.  Please let me know if you have any questions.

Regards,

Mitch

Hi uzsim,

Thank you for your inquiry about the SLABHIDDevice.dll API function hiddevice_getInputreport_interrupt().  To answer your question about why the returned number of bytes is always the same size as a maximum USB interrupt report (i.e. 64 bytes), I would first like to give you the link to AN532: HID Library API Specification.  Here you will find the API specification for  hiddevice_getInputreport_interrupt() in section 4.10 on page 12:

BYTE HidDevice_GetInputReport_Interrupt (HID_DEVICE device, BYTE*
buffer, DWORD bufferSize. DWORD numReports, DWORD* bytesReturned)

I am assuming from your statement that the variable "bytesReturned" is always 64 in your case - is that correct?  Is it also true that the values you pass to this function in the parameter "numReports" is 1?

Note that bytes returned will be a multiple of the maximum report buffer size times the number of reports returned:

"Each input report returned in buffer is stored on boundaries set by the maximum input report buffer
size. For example, if the maximum input report buffer size as returned by
HidDevice_GetInputReportBufferLength() is 64 and HidDevice_GetInputReport_Interrupt() returns
2 input reports, then bytesReturned will return with 128 bytes. The first input report starts at
buffer[0], and the second input report starts at buffer[64] regardless of the actual size of the report."  (AN532, section 4.10, page 12)

I hope this helps!  Please let me know if you have any questions.

Regards, 

Mitch

Hi uzslm,

Thank you for your reply and for your patience.  You are welcome for providing AN532.  I not aware of a newer version of AN532 - as far as I know the version I linked above is the current version.  AS for the SlabHIDDevice.dll version and release notes, I am looking into this.

The API function (see AN532, section 4.13, p.14)

WORD HidDevice_GetInputReportBuffferLength (HID_DEVICE device)

returns the maximum input buffer length for the device.  Note that "This function should be called to determine the appropriate buffer size for HidDevice_GetInputReport_Interrupt() and HidDevice_GetInputReport_Control()."

Additionally, you can call (see AN532, section 4.14, p.14)

WORD HidDevice_GetOutputReportBuffferLength (HID_DEVICE device)

to return the maximum output buffer size.  The bufferSize parameter of HidDevice_SetOutputReport_Interrupt() should not exceed the maximum output buffer size reported by HidDevice_GetOutputReportBufferLength().

Also relating to maximum HID report size is the fact that Silicon Labs devices can operate as low or full speed devices only.  For a full speed  device, the maximum interrupt report size (HID data reports are interrupt reports) is 64 bytes.  A report size of 90 should be possible for a high speed USB device (i.e. up to 1024 bytes), however this does not apply to Silicon Labs USB devices.  

I hope this helps.  Please let me know if you have any questions.

Regards,

Mitch

Hi uzsim,

Thank you for your inquiry about the SLABHIDDevice.dll API function hiddevice_getInputreport_interrupt().  To answer your question about why the returned number of bytes is always the same size as a maximum USB interrupt report (i.e. 64 bytes), I would first like to give you the link to AN532: HID Library API Specification.  Here you will find the API specification for  hiddevice_getInputreport_interrupt() in section 4.10 on page 12:

BYTE HidDevice_GetInputReport_Interrupt (HID_DEVICE device, BYTE*
buffer, DWORD bufferSize. DWORD numReports, DWORD* bytesReturned)

I am assuming from your statement that the variable "bytesReturned" is always 64 in your case - is that correct?  Is it also true that the values you pass to this function in the parameter "numReports" is 1?

Note that bytes returned will be a multiple of the maximum report buffer size times the number of reports returned:

"Each input report returned in buffer is stored on boundaries set by the maximum input report buffer
size. For example, if the maximum input report buffer size as returned by
HidDevice_GetInputReportBufferLength() is 64 and HidDevice_GetInputReport_Interrupt() returns
2 input reports, then bytesReturned will return with 128 bytes. The first input report starts at
buffer[0], and the second input report starts at buffer[64] regardless of the actual size of the report."  (AN532, section 4.10, page 12)

I hope this helps!  Please let me know if you have any questions.

Regards, 

Mitch

See if this help:

https://www.silabs.com/documents/public/application-notes/AN282.pdf

https://www.silabs.com/documents/public/example-code/AN282SW.zip

Hi Walter,

Thank you for your inquiry regarding modifying your project to use the LFRCO instead of the LFXO.  I have a few comments and questions:

1) Please note that there are certain accuracy requirements for Bluetooth applications which, if not met, can cause connection problems.  Section 4.1.2 on page 13 of UG136: Silicon Labs Bluetooth ® C Application Developer's Guide for SDK v2.x states (regarding the LFCLK):

"The accuracy of this clock depends on the operating mode of the device. When advertising or scanning, accuracy is not that important,
but when a connection is open the accuracy must be at least ±500 ppm. This clock can be driven either by LFXO, PLFRCO
(EFR32xG13 or xGM13), or LFRCO (EFR32xG2x or xGM2x), depending on the accuracy requirements. If applications only require advertising
or scanning, LFRCO can be used as the clock source. However, if Bluetooth connections are required, the clock source must
be either LFXO, PLFRCO (EFR32xG13 or xGM13) or LFRCO with High Precision Mode (EFR32xG22 or xGM22). When using
PLFRCO or LFRCO, the accuracy of the clock must be configured to ±500 ppm."

and 

"If none of LFXO, PLFRCO or LFRCO with High Precision Mode is connected but Bluetooth connections are required in the design,
sleep has to be explicitly disabled from the application. As mentioned in section 4.2.4 Sleep, if the LFCLK is not accurate enough, then
the sleep modes have to be disabled for Bluetooth connections to operate correctly."

Note that the EFR32BG21 device does not have a PLFRCO or an LFRCO with High Precision Mode.  Thus, you must use an external LFXTAL with the LFXO if your device will go into sleep mode.

2) At what point exactly after the call to  gecko_stack_init() does your program hang?

Thank you, and please let me know if you have any questions.  

Regards,

Mitch