Rpi3 Clock Stretching using Fleet variables


To get one of my i2c devices to operate properly on the rpi3, I need to do adjust the clock speed so that the connected i2c device plays nicely with the pi3 and gets me the right values. (note : this issue doesn’t exist on the pi2 due to the clock difference)

I’ve tested everything under raspbian and basically adding the following line to the config file fixes things.


My question : Is there a way to set this using fleet config variables ? I don’t want to edit each of my device config files one by one.

I’m aware of the RESIN_HOST_CONFIG_ way, but I can’t figure out the right implementation for it to work.
Tried several combinations, but so far nothing.

Thought I might just post here and the solution could be useful for somebody else in the future :slight_smile:

hey @xyala, have you set it as RESIN_HOST_CONFIG_dtparam to i2c1_baudrate=50000 since dtparam is the variable name. See for example the https://www.raspberrypi.org/documentation/configuration/config-txt.md.

Hey @xyala, one thing to note, is that there can be only one config name the same currently (only one RESIN_HOST_CONFIG_dtparam), so if you need to add more, then it’s better to set it in the config.txt directly, if you have access to the device. We are working on improving this, but it’s a current limitation… :hammer_and_wrench:

@nghiant2710 Ha! thanks, that’s one of the configs I haven’t tried actually.
Just ran a test, and for some reason this makes my code crash (node app) - which without this config line doesn’t make any error.
@imrehg ha! Thanks for the insight.

Error I have now:
‘12.10.17 09:51:14 (+0000) { Error: ENOENT: no such file or directory, open ‘/dev/spidev0.0’’

I reverted (removed the config var), and it seems that the error persists. Rebooted, same.
Could it have modified / broken something?

I don’t have physical access to the device right now so I can’t check things though (but tomorrow) - could it be that I have to re-flash ?

You should not need to reflash, maybe can try with mounting the SD card, and on the boot partition edit the config.txt, removing the dtparam=i2c1_baudrate=... line?

(there might be more than one, checking it why that might happen).

I will have access to that device tomorrow and will try to check the SD Card to see what’s going on there.

The other part might be that i2c1 is not enabled? So maybe these other two settings need to be set up as well:


We can try to add it to your config.txt remotely, and see if that fixes things? (since those are multiple dtparam settings that cannot be set from the env variables as of now in the same time…

@xyala Ah, I see one possible issue that caused it (and we’ll need to take care of this)


was already set, but since they are already dtparam, when setting the new value then they were replaced by the i2c1_baudrate setting (which is then will be listed 3x in the config.txt if the theory is correct)… so definitely have to fix it up, and retry…

Could you enable support access for the device from the actions tab, and send us the device dashboard link (in a PM?)

I see. I was suspecting something like multiple entries on the config file as well.

Granted support access to the device.

Cheers, indeed, the config.txt had these lines


instead of


We’ve updated it (including the baudrate to 500000 that you wanted to try) and rebooted the device. The error seems to be that the spi entry was removed by the earlier bug, and no spi devices were created. (fortunately I know what hardware you are using :stuck_out_tongue: )

So the final config.txt (just the relevant parts at the end of the file, not the commented out parts):


… and the app is back to work properly :tada:

Basically hit this issue, that we need to take a better care of… :frowning:


Awesome, thanks @imrehg!

So if I understand right, before I can use the fleet variables RESIN_HOST_CONFIG_dtparam to i2c1_baudrate=50000 I must wait for the issue to be fixed on resin’s side and use as alternative the config.txt method, correct?

Meanwhile I subscribed to the git threat :slight_smile: Glad my issue could help raise some additional flag there.

Quick note, you mention you set it to 500000 it’s 50khz I wanted to try haha, but seems like 500k yields the same result. So that works too. All good.

hey @xyala yeah, that is correct.

Sorry about missing the number of zeros (was reading some blogpost and those were speeding up i2c, and you wanted slowing down, right?)… :confused: So is it good this way? if not, happy to change it quickly to the desired value :stuck_out_tongue:

from the logs, the values that a read seem correct. I will double check tomorrow to make sure of it.
For now let’s leave it like that. And if needed I will try to adjust myself

Thanks a lot for your help!

1 Like

ok - to wrap things up and confirm. It’s works perfectly :slightly_smiling_face:

Really looking forward to not have to edit the config.txt file though.

1 Like