RSL10 I2C issues

Hello users,

I am currently building a complex sub-system using RSL10 as a part of my work. The system do consists of simultaneous usage of SPI, I2C, PDM and DIO pins ( using interrupts and DMA).

We are facing several I2C performance issue, of which i will pick the most important two :

  1. The configured clock doesn’t get generated : we configure the I2C clk for 400 Khz to generate from 24 Mhz SYSCLK ( by using the value of 19 in register) . But the output we observe is around 350 Khz. This can be even replicated in the RSL10 eval board which i am using. Can any gurus throw light on that ?
    (having said that SPI works fine in the same setup

  2. The second issue is the erratic behavior of missing stop-bits when a high priority interrupt pre-empt the I2C DMA interrupt. Most of such cases we get the bus-busy ( SDA to go low) all the time. DId you guys have any solutions for that. ( Note : This part i am testing on my custom hardware where lot of interrputs higher priority than I2C is happening)

thanks and regards

Hello Arun,

Thanks for reaching out to us. I am happy to help.

  1. I will see if I can recreate this issue regarding the clock frequency. Could share all or part of you Initialize() function to help me make sure we have the same settings?
  2. It seems like what you are describing, is that when a high priority interrupt happens during an I2C command, it finishes the command but is missing the stop condition? Is this happening during an I2C write or read?

Thank you

Hello again,
Your first issue in fact be your slave device stretching the clock. Can you tell me the part number for the device you are communicating with? One possible test is to disconnect your slave device and measure the clock frequency as the RSL10 attempts to communicate with it.

For your second question, try taking a look at the following post and see if it helps address your problems. I2C stop condition control does not work.

Thanks a lot Taylor Lee for opening up the case.

Apologize… since i was on travelling didn’t get time to response.

Please see the below replies

Could share all or part of you Initialize() function to help me make sure we have the same settings?

System initialize which runs at power on (relevant to i2c):
/* Configure the current trim settings for VCC, VDDA */

/* Start 48 MHz XTAL oscillator */

/* Wait until VDDRF supply has powered up */


/* Enable BLE power switches */

/* Remove BLE isolation */
/* Provide Power to BLE */

/* Start the 48 MHz oscillator without changing the other register bits */

/* Enable the 48 MHz oscillator divider using the desired prescale value
 *  for 24 MHz clock
 *  For Rf clock
 *  Clk source = OSCILLATOR (48Mhz)
 *  		   = Source / CK_DIV_1_6_Prescaler
 *  Prescaler  = 2;
 *  		   = 48 MHz/2
 *  RF Clk     = 24 MHz
 *  (used as SYSCLK)				*/

/* Wait until 48 MHz oscillator is started */

/* Switch to (24 MHz) oscillator clock */
Sys_Clocks_SystemClkConfig(JTCK_PRESCALE_1 | EXTCLK_PRESCALE_1 |

/* Configure clock dividers for
 * slow clock at 1 MHz
 * BB clock at 8 MHz
 * USR clock at 24 MHz */

/* Configure clock dividers */

/* Enabling BB Clock and making controller in active mode */


Please let me know if you need any more init code

Yes checked that … still the frequency is the same. We have tested independently with adwark progammer(I2C analyzer) to the same pcb, but was showing the correct clock frequency (without any clock stretching).

This part its happening during when RSL10 is in Master Read
( for example code can run without error for 1 hour, but during one instant when External interrupt happens at the same boundary of DMA2 interrupt, I2C is not generating stop bits )

Somehow i made some recovery code to recover from this error ( I2C bus clear from cmsis code).

I have taken a look at this part… its already taken care in code ( as you can see attached init code )

Welcome back Akrece, I hope you had a safe trip!
It seems most likely you are missing the necessary external pull-up resistors on the I2C signals (I will look into why the internal strong pull-up is not enough. This would explain why the Aardvark sees the proper frequency when it is connected, with pull-ups enabled. Please review your hardware and let me know what you find.
Otherwise, we have released the latest RSL10 SDK V3.6 which includes number of improvements. Please try using the latest SDK and let me know if the behavior changes. Cheers!

Thanks again for the fast response Taylor Lee. The pull-up resistors is presented in hardware at 10 K ohm for both SCL and SDA.

Eventhough we are having mixed working environment in our company, but i believe i am using latest ide version with latest SDK. … Attach below is the some excerpts during compilation process from which you can judge whether i am using latest SDK

(RTE version used 3.6.465)

compile time Messages at the end :

Building target: xxxxx_target_name_xxxx.elf
Invoking: Cross ARM C Linker
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -fcommon -Wunused -Wuninitialized -Wall -Wmissing-declarations -Wlogical-op -Waggregate-return -Wfloat-equal -g3 -T xxxx
Using built-in specs.
Reading specs from c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/…/…/…/…/arm-none-eabi/lib/nano.specs
rename spec link to nano_link
rename spec link_gcc_c_sequence to nano_link_gcc_c_sequence
rename spec cpp_unique_options to nano_cpp_unique_options
COLLECT_LTO_WRAPPER=c:/program\ files\ (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/lto-wrapper.exe
Target: arm-none-eabi
Configured with: /mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/src/gcc/configure --build=x86_64-linux-gnu --host=i686-w64-mingw32 --target=arm-none-eabi --prefix=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-mingw --libexecdir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-mingw/lib --infodir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-mingw/share/doc/gcc-arm-none-eabi/info --mandir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-mingw/share/doc/gcc-arm-none-eabi/man --htmldir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-mingw/share/doc/gcc-arm-none-eabi/html --pdfdir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-mingw/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-mingw-wildcard --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-headers=yes --with-newlib --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-mingw/arm-none-eabi --with-libiconv-prefix=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/build-mingw/host-libs/usr --with-gmp=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/build-mingw/host-libs/usr --with-mpfr=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/build-mingw/host-libs/usr --with-mpc=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/build-mingw/host-libs/usr --with-isl=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/build-mingw/host-libs/usr --with-libelf=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/build-mingw/host-libs/usr --with-host-libstdcxx=’-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm’ --with-pkgversion=‘GNU Arm Embedded Toolchain 10-2020-q4-major’ --with-multilib-list=rmprofile,aprofile
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20201103 (release) (GNU Arm Embedded Toolchain 10-2020-q4-major)
COMPILER_PATH=c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/;c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/;c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/…/…/…/…/arm-none-eabi/bin/
LIBRARY_PATH=c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/thumb/v7-m/nofp/;c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/…/…/…/…/arm-none-eabi/lib/thumb/v7-m/nofp/;c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/arm-none-eabi/lib/thumb/v7-m/nofp/;c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/;c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/;c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/…/…/…/…/arm-none-eabi/lib/;c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/arm-none-eabi/lib/
COLLECT_GCC_OPTIONS=’-mcpu=cortex-m3’ ‘-mthumb’ ‘-O0’ ‘-fmessage-length=0’ ‘-fsigned-char’ ‘-ffunction-sections’ ‘-fdata-sections’ ‘-fcommon’ ‘-Wunused’ ‘-Wuninitialized’ ‘-Wall’ ‘-Wmissing-declarations’ ‘-Wlogical-op’ ‘-Waggregate-return’ ‘-Wfloat-equal’ ‘-g3’ ‘-T’ ‘xxx/RTE/Device/RSL10/sections.ld’ ‘-nostartfiles’ ‘-specs=nano.specs’ ‘-v’ ‘-o’ ‘xxxxx_target_name_xxxx.elf’ ‘-mfloat-abi=soft’ ‘-march=armv7-m’
c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/collect2.exe -plugin c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/liblto_plugin-0.dll -plugin-opt=c:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/lto-wrapper.exe -plugin-opt=-fresolution=C:\Users\xx\AppData\Local\Temp\ccFizrRp.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lg_nano -plugin-opt=-pass-through=-lc_nano -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc_nano --sysroot=c:\program files (x86)\onsemi\ide_v4.1.2.79\arm_tools\bin…/arm-none-eabi -X -o xxxxx_target_name_xxxx.elf
-Lc:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/thumb/v7-m/nofp -Lc:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/…/…/…/…/arm-none-eabi/lib/thumb/v7-m/nofp -Lc:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/arm-none-eabi/lib/thumb/v7-m/nofp -Lc:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1 -Lc:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc -Lc:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/lib/gcc/arm-none-eabi/10.2.1/…/…/…/…/arm-none-eabi/lib -Lc:/program files (x86)/onsemi/ide_v4.1.2.79/arm_tools/bin/…/arm-none-eabi/lib --gc-sections -Map --start-group
COLLECT_GCC_OPTIONS=’-mcpu=cortex-m3’ ‘-mthumb’ ‘-O0’ ‘-fmessage-length=0’ ‘-fsigned-char’ ‘-ffunction-sections’ ‘-fdata-sections’ ‘-fcommon’ ‘-Wunused’ ‘-Wuninitialized’ ‘-Wall’ ‘-Wmissing-declarations’ ‘-Wlogical-op’ ‘-Waggregate-return’ ‘-Wfloat-equal’ ‘-g3’ ‘-T’ ‘-nostartfiles’ ‘-specs=nano.specs’ ‘-v’ ‘-o’ ‘xxxxx_target_name_xxxx.elf’ ‘-mfloat-abi=soft’ ‘-march=armv7-m’
Finished building target: xxxxx_target_name_xxxx.elf

Thank you for sharing that info, it does look like you are using the latest SDK release :+1:.
If you have the proper pull-up resistors, then the clock stretching is likely intentionally coming from your peripheral device. Another way to verify this is to put a small series resistor (<100ohm) into the SDA signal and measuring the clock with an oscilloscope. This will create a small difference in voltage, depending on which device is holding the line low. I can explain this further if you are interested.

Otherwise, was this link able to help with the missing stop condition?
I2C stop condition control does not work

It is possibility is that a 10k ohm pull-up resistor may not be sufficient to provide a fast enough rise time to avoid the RSL10 believing the peripheral is attempting to stretch the clock. To achieve 400kHz operation, a stronger pull-up resistor is recommended (4.7kohm or 2.2kohm).

Another important consideration is the length and capacitance of your I2C lines. I2C was only designed for traveling short distances ( <8inchs). If you are designing a large PCBA, or trying to communicate over a cable (like HDMI does) then you will want to have a set of pull-up resistors near each device.

If you are interested, I find to be a great resource for explaining the finer details of I2C. Otherwise, I have a lot of experience debugging I2C issues and am happy to answer any more questions.

I guess this is more to hardware than software solution… So that’s why i am marking this as Solution, even though i am not able to solve the issue using software.

We did try different Pull-up resistors, eventhough it can improve the rise time, the change in frequency still perplexing, given the fact that that the same sysclk is used to generate SPI clk without any issues.

Thanks a lot for your valuable suggestions @taylor.lee

1 Like