The latest USBXpress SDK installer, version 6.7.6, can be found here, under the 'Direct Access Driver Software' for Windows 7/8/8.1/10 link: https://www.silabs.com/products/development-tools/software/direct-access-drivers

or here: https://www.silabs.com/documents/public/software/USBXpressHostSDK-Win.zip

you should use the GCC lib and I think it should work.

https://community.arm.com/developer/tools-software/tools/f/keil-forum/17118/conversion-of-integer-to-ascii-for-display

But why not try to implement this by your own?

Similar operation like used in below example could attain that.

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.7\util\third_party\mbedtls\library

https://github.com/SiliconLabs/peripheral_examples/blob/master/series2/cryptoacc/cryptoacc_aescrypt/src/main.c

 

If you are only need to print ADC value to a console, you may take a look at KBA like below:

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2020/03/26/using_printf_in_mcuapplication-lyuZ

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2014/11/19/floating_point_print-7R9j

There is a 4 byte management overhead per data object whose size is less than or equal to 128 bytes and an 8 byte management overhead per data object whose size is greater than 128 bytes. This information, along with a high level comparison of the various Silicon Labs non-volatile data storage implementations can be found in Table 5.1 of UG103.7: Non-Volatile Data Storage Fundamentals. NVM3 is our latest and recommended implementation.

Our NVM3 library is equip with two object types: data and counters. As such, an array will be treated as one large data object. This means that any time a value in the array is modified, the entire data object will need to be written to flash. If only portions of the array are changing with each new data write, this can cause superfluous flash erases/writes. To optimize flash 'wear' by minimizing flash erase/write cycles, it's best to size the NVM3 objects into blocks of data that are expected to change with each write.

For your implementation, are you expecting that all of the elements in a 25 element UART transfer will have changed? If so, then splitting your large array into 20 smaller arrays is definitely better for wear-leveling. If all 500 are expected to change, you could hold off and implement a single write of the entire array. If only a few elements are expected to change, creating 500 individual objects, one for each element of the array, will be most optimal. The NVM3 library implements a check such that unchanged data does nothing to the NVM3 instance (no additional writes), so code can simply call and NVM3 write data for each element, and the library will take care of the rest.

Here are a few additional NVM3 resources that you may find helpful:

• https://www.silabs.com/documents/public/application-notes/an1135-using-third-generation-nonvolatile-memory.pdf
• https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2018/11/21/nvm3_example-DP9N

Our NVM3 library is equip with two object types: data and counters. As such, an array will be treated as one large data object. This means that any time a value in the array is modified, the entire data object will need to be written to flash. If only portions of the array are changing with each new data write, this can cause superfluous flash erases/writes. To optimize flash 'wear' by minimizing flash erase/write cycles, it's best to size the NVM3 objects into blocks of data that are expected to change with each write.

For your implementation, are you expecting that all of the elements in a 25 element UART transfer will have changed? If so, then splitting your large array into 20 smaller arrays is definitely better for wear-leveling. If all 500 are expected to change, you could hold off and implement a single write of the entire array. If only a few elements are expected to change, creating 500 individual objects, one for each element of the array, will be most optimal. The NVM3 library implements a check such that unchanged data does nothing to the NVM3 instance (no additional writes), so code can simply call and NVM3 write data for each element, and the library will take care of the rest.

Here are a few additional NVM3 resources that you may find helpful:

• https://www.silabs.com/documents/public/application-notes/an1135-using-third-generation-nonvolatile-memory.pdf
• https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2018/11/21/nvm3_example-DP9N

doynax, could you please create a technical support ticket in order to work with our team more directly. You can create a ticket here:

http://www.silabs.com/support/pages/contacttechnicalsupport.aspx

1. I think there is no problem for the NCP-host to wakeup EFR32 via a GPIO.

2/3. You may need post your question to BLE forum to see if a LFXO is needed. and check if below KBA helps or not if you need support BLE deep sleep/EM2.

https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2019/06/18/kba_bt_0409_usingtheplfrcoaslow-frequencyclo-vPoh

https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/02/22/using_energy_modesw-B4eB

https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2019/02/25/kba_bt_0207_periodi-oDcf

I've also tested the main_single_differential_polled example on a BRD4180A radio board using the modified initADC() function you provided, but I am unable to reproduce the issue you've observed. What connections are you making with PC4/5 for your measurements? Can you verify that the expected voltage is present on these pins using an oscilloscope?

Also, please note that when measuring an internal supply (Vddx) on the ADC positive input, the PINNEG needs to be odd (1, 3, 5,...):

initSingleInput.negInput = iadcNegInputGnd | 1;

The ADC0INT bit needs to be cleared by software before initiating a new conversion. That is what is causing the ADC error and overrun condition.

We also provide several ADC example projects in the 8-bit SDK that could provide some insight to proper configuration. Simplicity Studio displays a list of example projects from the Launcher perspective with the C8051F350 device selected under Getting Started>Software Examples.

Please provide the source code for which you encounter this issue.

Yes, I think AN1112 is a good start point for you.