EEPROM I2C

[MagoKimbra]

In the scheme there seems to be the I2C eeprom, but I can't find it, I did the scanning on the port, but nothing.
There is and if there is that address has, normally it should be 0x50.
Thanks! |

[chrissbarr]

Hi @MagoKimbra,

There's a footprint on the PCB to suit an I2C EEPROM, but no actual EEPROM IC has been installed on the boards we are shipping. It is not included because the flash emulation in the Marlin STM32 HAL seemed to make it unnecessary. Could the flash emulation work for what you need?

We are still very early in the life of these boards - if you have feedback that you think the EEPROM IC would be a good thing to have, let me know, and we will take that into account in future revisions.

Let me know if you'd like any more information!

[MagoKimbra]

Hi, I don't use Marlin, I use MK4duo, a firmware born by Marlin 5 years ago, but completely different today.
I'm starting to program on Rumba32 and I'm on the right track almost everything works today, except for communicating to the SPI TMC2130 drivers and the EEPROM.
For the driver I tried to install Marlin 2.0 to check and even that doesn't communicate, so I think it's the driver I use for tests, I bought another one, see.
For the EEPROM thinking that there was already, I was going crazy looking for the address, but if it's not there it's normal.
EPPROM flash, yes good, now I have to try to see if I can make it go like on Arduino DUE, but at least on this one if you download a new firmware even if the EEPROM configuration has not changed you lose it anyway. I prefer the I2c at least it is always present after a new download ...
Where is the place on the board for the i2c, if anything I install one for test.
Hello and thanks.

[chrissbarr]

Hi @MagoKimbra,

Ah, I understand about MK4duo (I thought your username was familiar, should have realised!).

We have had someone else report having trouble with TMC2130 SPI in the last few days, I am looking into it at the moment to see what the problem might be - so, it might not just be you. I will let you know if there is any discovery.

Sorry for the confusion about the EEPROM. You make a good point about losing the configuration, I will make a note and we will look at adding the IC back for future batches.

For adding one yourself, there are pads for a SOT-23-5 EEPROM and an 0603 capacitor (100nF or similar), here:

The pinout is like this:

The pinout was to suit the 24LC16BT-I/OT I2C EEPROM, but it is a common footprint I believe so other parts may work as well. The ceramic capacitor is recommended, anything in an 0603 size, 100nF - 1uF, 6.3V or greater should work fine (probably can work without it - but for production, we would definitely include it).

Let me know if you would like any more information.

[MagoKimbra]

I'm glad you know me.
Unfortunately today Marlin passed me for processors, I was the first with a firmware based on marlin to use Arduino DUE, but then I stopped, not having much time and above all because I'm alone. Today Marlin has many supported processors, so I decided to shoot with STM32 and the rumba32 which I think is an excellent card.
I hope the SPI driver problem can be solved easily.
Meanwhile, I can hardly do with the flash ram for EEPROM emulation and then we see the next developments you will make ..
Thank you and good day.

[MagoKimbra]

I know that the problem is this the 4 pins SDI, SCK, CS, and SDO are sequential and are the 2, 3, 4 and 5, while from the diagram, SDO you put it on SLEEP pin 6, at least I see it from scheme.
I hope I'm wrong, but if it were so it's a mess to edit on the card ...

In fact it would seem that the writing takes place, I tried to write different micro-steps and to move and the motor turns more or less revs according to the microsteps (of course without changing the steps per mm), but does not receive any information from the driver ...

[chrissbarr]

Hi @MagoKimbra,

You're right - I've just found the same thing here, and have confirmed it in testing.

Firmware will write to the drivers OK, but can not receive anything from them. We used the SPI drivers in testing, but looking at our test procedure we only tested writing to them / adjusting settings, nothing that required the feedback.

I'm don't think there's an easy fix on the current boards, as the tracks are under the jumper pins and can't easily be cut / modified. Some way of jumping the outermost pins should work, but is not easy to do.

I'll keep looking into this and will see if there are any other solutions... We can get this fixed in the next batch of boards, but will have to find another solution for anyone else with a current board.

Thanks for investigating!

Added:

It looks like the easiest way to make this work at the moment is to replace the jumper with a wire connecting the top and bottom pins, like so:

[chrissbarr]

I've added a notice to our product page for RUMBA32. Tomorrow I will look more closely and see if there is a fix to get both SPI and normal modes working.

Sorry for the trouble you've run into here! We will get this fixed in the next batch, and if you want we can exchange your board for an updated one then.

[chrissbarr]

Just in case anyone else runs across this issue here, our current documentation for the SPI fix is below:

[MagoKimbra]

Ok, perfect ... Yesterday I run my delta with the rumba32 and everything goes perfectly, bltouch, sd, TMC2130, DHT, Nextion, etc etc.
Thanks, and I ask you for a courtesy, could you mention the MK4duo firmware that runs on your card?
I thank you if you do.
https://github.com/MKFirmware/MK4duo

[chrissbarr]

Hi @MagoKimbra,

Yes, I enjoyed that video you linked me to - it looks like everything is running very well with the MK4duo firmware. Congratulations on getting it all working well! I'd be happy to mention the MK4duo firmware, I'll add a list of supporting firmwares to the main Git readme shortly.

[lorenzing]

Just in case anyone else runs across this issue here, our current documentation for the SPI fix is below:

Hi @chrissbarr I think I have the same problem even in the newly purchased V1.0E version. Is it so or am I wrong? Thank you very much for your help.

[leseaw]

its the same :(

[robustini]

[CGuasco]

Hello, the eeprom you recommend (24lc16) has a software protocol different from the i2c standard: the first byte must be 0101 plus the page (3 bits), while the standard protocol is 0101 plus 3 bits of the hardware address. since is on the same i2c bus, it would not be possible to insert other peripherals.
Putting a 24lc256 works perfectly, but it has a totally different footprint (8 pins instead of 5).
Am I wrong?
I only see one i2c bus.

[chrissbarr]

Hi @CGuasco,

My reading of the 24LC16 datasheet is that it will consume addresses 0x50 - 0x57 on the I2C bus. This means it would not be possible to use the 24LC16 and another device with an address in that range on the same bus. Devices with addresses outside of that range should not have a conflict.

You are correct that there is only one I2C bus broken out on the RUMBA32 board.

I believe there are a number of I2C EEPROM ICs that adhere to both the addressing protocol you desire and the SOT-23-5 footprint on RUMBA32. I believe the 24AA32AT is one such part, I'd suggest checking if that looks suitable to you.

[phongshader]

If I were to solder on an eeprom chip and capacitor, as you intended, which chip would you recommend? ‎24AA32AT or 24LC16BT?

[chrissbarr]

Hi @phongshader,

Any of the above should be suitable, however I have not tested the 24AA32AT so would recommend that last.

I am planning to include the 24LC64T-I/OT (bigger, 8kB cousin of the 24LC16BT) on future versions of RUMBA32. I have tested this part and it works with Marlin's I2C EEPROM implementation with no modifications required. Can confirm pinout etc. match the RUMBA32 boards in circulation (this is what I am testing on). This would be my first recommendation if available.

[phongshader]

Hi @chrissbarr
I received my board yesterday and installed the eeprom chip. I have a question about the orientation of the eeprom chip on the board. I paid no attention to any markings on the board since the pins are asymmetrical and can only be installed one way. After the chip was installed I took a closer look at the markings on the board and the chip. If I were to install the chip based on the board and chip markings I would have to install the chip upside down.

I know this is a MKS board but I just wanted to get your feedback.
P.S. after looking at the data sheet it looks like the way I installed it is the correct way. It's odd that the chip is marked the way it is. ¯_(ツ)_/¯

[chrissbarr]

Hi @phongshader,

Hmm, I've had a look at the datasheets for the 24AA32AT and 24LC64T-I/OT, and the datasheets actually don't show the SOT-23 packages as having any polarity marking. All other packages do - see below:

This is probably because the SOT-23 is smaller than the other packages, and are polarised anyway, so this has not been included. I would guess that the mark on the actual package could just be from the moulding process (I forget the term - but many components have 2 marks, one from manufacture, and another printed on for polarity. Check the STM32 on the board, I believe it has two marks that are in different corners.)

I agree that the pinout should be correct the way you have installed it. If you run into trouble, let me know and we'll figure it out.

[phongshader]

I made my conclusion based on the silk screen image

found here http://ww1.microchip.com/downloads/en/DeviceDoc/05L_SOT-23_OT_C04-00091f.pdf
Seems like they would know although nothing is explicitly stated.

Thanks for checking in.

[chrissbarr]

Looks good from that image then. As mentioned previously, I'm using the 24LC64T-I/OT myself on one of these boards for testing purposes and it's been happy in this orientation.

All of the I2C EEPROM ICs I can find from Microchip in SOT-23 look to have the same pinout, so I'd say it's something of a defacto standard at least for this manufacturer (I haven't looked around much beyond that).

[phongshader]

how do I enable eeprom in firmware?
#define EEPROM_SETTINGS // Persistent storage with M500 and M501
//#define DISABLE_M503 // Saves ~2700 bytes of PROGMEM. Disable for release!
#define EEPROM_CHITCHAT // Give feedback on EEPROM commands. Disable to save PROGMEM.
#define EEPROM_BOOT_SILENT // Keep M503 quiet and only give errors during first load
#if ENABLED(EEPROM_SETTINGS)
#define EEPROM_AUTO_INIT // Init EEPROM automatically on any errors.
#endif
when issuing M500
>>> m500 SENDING:M500 echo:No EEPROM.
The components I used are CAP CER 1UF 6.3V X7R 0603 and 24LC64T-I/OT

[chrissbarr]

Try this:

#define I2C_EEPROM
#define MARLIN_EEPROM_SIZE 0x2000             // 8KB (24LC64T-I/OT)

#define EEPROM_SETTINGS     // Persistent storage with M500 and M501
//#define DISABLE_M503        // Saves ~2700 bytes of PROGMEM. Disable for release!
#define EEPROM_CHITCHAT       // Give feedback on EEPROM commands. Disable to save PROGMEM.
#define EEPROM_BOOT_SILENT    // Keep M503 quiet and only give errors during first load
#if ENABLED(EEPROM_SETTINGS)
  //#define EEPROM_AUTO_INIT  // Init EEPROM automatically on any errors.
#endif