Marlin: [2.0.x] I2C_EEPROM broken on Due (not booting)

[dembach]

Configuration_adv.txt
Configuration.txt

if I2C_EEPROM is defined on Due, the Due wont boot.......(i.e. RAMPS-FD-V2.2)

/**
 * RAMPS-FD v2
 *
 * EEPROM supported
 * Use 1k thermistor tables
 */

#define BOARD_NAME         "RAMPS-FD v2"

#include "pins_RAMPS_FD_V1.h"

#undef INVERTED_HEATER_PINS
#undef INVERTED_BED_PINS
#undef INVERTED_FAN_PINS

#define I2C_EEPROM

if i disable the I2C_EEPROM it is working.... but i want to save settings on EEPROM ;-)

[Bob-the-Kuhn]

Where did you get a RAMPS-FD-V2.2?

i have a V1. I'd much rather have a V2.

[dembach]

@Bob-the-Kuhn I build it on my own....still got a second 2.2 board here, unpopulated....

and made a stencil for SMD also.... maybe i can build you one .....

i can send you some photos.....

[Bob-the-Kuhn]

@ejtagle, @teemuatlut - isn't there a virtual EEPROM for Due?

I remember trying the virtual disk on the native USB port but didn't succeed. Windows showed a mass storage device but there was a problem starting it.

[cjsoong]

@dembach
I use RAMPS-FD V2.1 is no problem.
You check the i2c bus & SMD parts soldering

[Bob-the-Kuhn]

@dembach - you're much more ambitious than I am.

How much do you want to build a second one?

How much for the board & what ever extra parts you have?

[Bob-the-Kuhn]

@csjoong - where did you get the 2.1?

[cjsoong]

@Bob-the-Kuhn
https://item.taobao.com/item.htm?spm=a230r.1.14.107.524345baMkb6Zj&id=544866465374&ns=1&abbucket=15#detail

[ejtagle]

@Bob-the-Kuhn : Yes, there is a virtual e2prom for DUE. Enable EEPROM settings, and disable both SPI and I2C eeproms and you will get it.
Regarding the USB mass storage device, it is strange. If the SD card works within Marlin, then it should work under Windows also with an small caveat: If Marlin is printing or using the SDCard, then windows will not be able to access or mount it
I will retest with the latest version to make sure it still works...

[dembach]

@cjsoong , @Bob-the-Kuhn : i do not connect any shield, just enable I2C_EEPROM .

@Bob-the-Kuhn : i just need the money for the components... about 20€. i do it as a hobby...

you may call me: [phone]

[dembach]

@cjsoong :
really wondering , the resistors in the middle on your 2.1 are not populated.... they just shorted them..

R502,R503,R504,R505 | SM0805 | 22R |

says the BOM of 2.1 , so why they replaced them with 0 Ohms ?
here is the BOM : RAMPS FD 2.1

Also it looks horrible, also the placement of the EEPROM is a little bit disaligned... not too nice....

[cjsoong]

@dembach
V2.1 temperature sensing input originally used 1K pull-hi, but after setting the temperature display has been wrong, so I changed it to 4.7k pull-hi

[tig33r]

@dembach are you still ready to sell one piece FDv2.2?

[dembach]

@tig33r :
the first one is reserved for @Bob-the-Kuhn , because he contributes much to Marlin...

[tig33r]

@dembach I do not want to buy, just did not read thread carefully and was thinking you have only one piece. Thats why I asked. :)

[dembach]

@tig33r :
i do them on my own.... just for hobby purpose..... i have got 2 pcb´s here.... one is ready and working now...
i can order 10 more pcb´s for a small price and solder them with connectors as required by the user.

[dembach]

back to topic:
if I2C_EEPROM is defined on Due, the Due wont boot.......
it has nothing to do with the connected shield, because it even wont boot if nothing is connected.
even the eeprom is not accessable, it should boot but claim about the missing eeprom. right ?

[cjsoong]

@ @ @dembach
Without EEPROM, the boot message will look like this and Boot needs to wait a long time
start
echo: PowerUp
Marlin bugfix-2.0.x

echo: Last Updated: 2018-01-20 | Author: (soong, 2018-01-24a)
echo: Compiled: Feb 5 2018
echo: Free Memory: 84104 PlannerBufferBytes: 1344
echo: EEPROM version mismatch (EEPROM =? Marlin = V50)
echo: Hardcoded Default Settings Loaded
echo: SD init fail

[dembach]

yes.. that's the way it works right now.
but I cannot enable eeprom on the firmware

[dembach]

how long does it take to boot ? minutes ?

[cjsoong]

@dembach
If it is power on about 15~20 seconds
Press reset to restart for about 5 seconds

[Bob-the-Kuhn]

Did you ever get your I2C EEPROM working?

I had a pleasant surprise. I was trying to see what happened when the EEPROM was enabled but not present. As far as I can tell my Due + RAMPS_FD V1 rev A has an EEPROM. At least it doesn't complain, M501 CRCs match the M500 ones and the config gets restored after powering down for a couple of minutes.

I think I have a RAMPS FD V2.1 coming from China. At least they've charged my credit card.

[dembach]

@Bob-the-Kuhn : RAMPS-FD 1.a does not have an EEPROM. there are several upgrades available for EEPROM on RAMPS-FD 1.a, but it is not worth the money, due to the design issues @bobc himself pointed out.
V 1.a is just for the bin...
i am just building a second RAMPS_FD 2.2.
@tig33r : if you want one, just contact me. The buyer decides wich connectors to be used on the Board i.e. for the Steppers or Power (custom build)

[tig33r]

@dembach I just read more about ramps-fd and now I am kinda interested how this board works. Pls give me your email or smth to contact.

[Bob-the-Kuhn]

Some progress on root cause.

TwoWire::begin() is being called before the twi instance is being created. That results in a call to an error stop routine.

Time to call it a night.

[Bob-the-Kuhn]

The routine __libc_init_array pulls in PrintCounter::PrintCounter(): super() in printcounter.cpp which starts the EEPROM read cycle.

This is done before setup() in Marlin_main.cpp is called.

The config info is read from the EEPROM as part of setup(). By this time the TWI instance has been created so the EEPROM accesses work.

I don't see an opportunity to delay calling PrintCounter because it's a library function.

The only other option that comes to mind is to create the TWI instance as either part of printcounter.cpp (between lines 31 & 32) or as part of the EEPROM read function. The problem is then how to keep from creating a second instance of TWI which I assume will cause a compiler error.

Still haven't found where the TWI instance is created.

[Bob-the-Kuhn]

@thinkyhead - need your help on this. Can you suggest a solution?

As best I can tell the TWI instance creation problem is because TwoWire Wire = TwoWire(WIRE_INTERFACE, Wire_Init, Wire_Deinit); and TwoWire Wire1 = TwoWire(WIRE1_INTERFACE, Wire1_Init, Wire1_Deinit); are not being called by the C++ function __libc_init_array().

Below are the compile errors I see when PRINTCOUNTER is enabled. They're finally making sense to me but I don't know how to fix it.

Compiling .pioenvs\DUE\libd22\Wire\Wire.cpp.o
In file included from C:\Users\bobku\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.cp

p:25:0:
C:\Users\bobku\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.h: In constructor 'TwoWi
re::TwoWire(Twi*, void (*)(), void (*)())':
C:\Users\bobku\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.h:96:7: warning: 'TwoWir
e::twi' will be initialized after [-Wreorder]
Twi *twi;
^
C:\Users\bobku\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.h:72:10: warning:   'uin
t8_t TwoWire::rxBufferIndex' [-Wreorder]
uint8_t rxBufferIndex;
^
C:\Users\bobku\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.cpp:95:1: warning:   whe
n initialized here [-Wreorder]
TwoWire::TwoWire(Twi *_twi, void(*_beginCb)(void), void(*_endCb)(void)) :
^
In file included from C:\Users\bobku\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.cp
p:25:0:
C:\Users\bobku\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.h:108:16: warning: 'TwoW
ire::status' will be initialized after [-Wreorder]
TwoWireStatus status;
^
C:\Users\bobku\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.h:90:30: warning:   'voi
d (* TwoWire::onBeginCallback)()' [-Wreorder]
void (*onBeginCallback)(void);
^
C:\Users\bobku\.platformio\packages\framework-arduinosam\libraries\__cores__\sam\Wire\src\Wire.cpp:95:1: warning:   whe
n initialized here [-Wreorder]
TwoWire::TwoWire(Twi *_twi, void(*_beginCb)(void), void(*_endCb)(void)) :

[rafaljot]

@cjsoong could you ask RAMPS-FD 2.1 seller to sell it by Aliexpres or something with shipping to Europe?

[thinkyhead]

@Bob-the-Kuhn — From what I can gather this type of error comes from having an initializer list that's in a different order than the data members. You might have already seen this:

Bad:

class test {
  test(): bar(2), foo(1) { }
  int  foo;
  long bar;
};

Good:

class test {
  test(): foo(1), bar(2) { }
  int  foo;
  long bar;
};

It's not clear from the error message you posted where the root of the error is, but I seem to remember running into the same thing and being a bit stumped. I'll try doing a Due build with PRINTCOUNTER again soon and see if I can disentangle it.

[bobc]

Generally, in what order does C++ call constructors? Is it defined by the
standard?

On 4 March 2018 at 08:52, Scott Lahteine [e-mail] wrote:

@Bob-the-Kuhn https://github.com/bob-the-kuhn — From what I can gather
this type of error comes from having an initializer list that's in a
different order than the data members. You might have already seen this:
Bad:

class test {
test(): bar(1), foo(2) { }
int foo;
long bar;
};

Good:

class test {
test(): foo(1), bar(2) { }
int foo;
long bar;
};

It's not clear from the error message you posted where the root of the
error is, but I seem to remember running into the same thing and being a
bit stumped. I'll try doing a Due build with PRINTCOUNTER again soon and
see if I can disentangle it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/9484#issuecomment-370212525,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7VR8RDVaG7ijzTH9zMqYvjZyeN5naLks5ta6svgaJpZM4R4v2i
.

[dembach]

Welcome @bobc ... cool to see you also here .....

[p3p]

@thinkyhead member variable initialisation is always done in declaration order, depending on compiler you will get a warning if the initialiser list order and declaration order mismatch but that should be all.

@bobc static variable construction order is undefined, and a pain in the ..., there are workarounds. I had to hook in before global initialisation in the LPC176x platform to start the systick timer as millis() wasn't updating before all the statics tried to initialise.

[Bob-the-Kuhn]

Fixing the warnings didn't help.

As I understand it the linker creates a list of the objects to be created by the C++ function __libc_init_array().. When it creates the PRINTERCOUNTER object it hasn't yet created the TWI objects yet. Creating the PRINTERCOUNTER object results in calling loadStats which is what actually does the EEPROM read.

I'm going to see if I can move the loadStats into the Marlin_main setup section.

[p3p]

@Bob-the-Kuhn As you say all statics will be initialised / constructed before control is passed to Marlin, perhaps even before the framework can initialise, if something is a static no hardware access should be performed in the constructor, even the assumption that clocks are started could be wrong.

[Bob-the-Kuhn]

I was able to move loadStats.

PR #9937 has the code changes.

[Bob-the-Kuhn]

@dembach - PR #9937 has been merged. Does it work with the latest bugfix-2.0.x?

[dembach]

Let me check later... I will check that in 2 hours, when I am back home

Bob-the-Kuhn [e-mail] schrieb am Di., 6. März 2018, 18:25:

@dembach https://github.com/dembach - PR #9937
https://github.com/MarlinFirmware/Marlin/pull/9937 has been merged.
Does it work with the latest bugfix-2.0.x?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/9484#issuecomment-370860085,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIlM5d8pwRvvai0FeoROmEcWJwnY-IA6ks5tbsacgaJpZM4R4v2i
.

[dembach]

working.... perfect !!!!!

echo:EEPROM version mismatch (EEPROM=? Marlin=V52)
echo:Hardcoded Default Settings Loaded
ok
**echo:Settings Stored (725 bytes; crc 57363)**
ok
start
echo:PowerUp
Marlin bugfix-2.0.x

echo: Last Updated: 2018-01-20 | Author: (none, BiQu Kossel+)
echo:Compiled: Mar  6 2018
echo: Free Memory: 82928  PlannerBufferBytes: 1344
**echo:V52 stored settings retrieved (725 bytes; crc 57363)**
echo:  G21    ; Units in mm
echo:  M149 C ; Units in Celsius

echo:Filament settings: Disabled
echo:  M200 D1.75
echo:  M200 D0
echo:Steps per unit:
echo:  M92 X100.00 Y100.00 Z100.00 E1025.00
echo:Maximum feedrates (units/s):
echo:  M203 X200.00 Y200.00 Z200.00 E25.00
echo:Maximum Acceleration (units/s2):
echo:  M201 X1000 Y1000 Z1000 E1000
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo:  M204 P1000.00 R1000.00 T1000.00
echo:Advanced: S<min_feedrate> T<min_travel_feedrate> B<min_segment_time_us> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
echo:  M205 S0.00 T0.00 B20000 X10.00 Y10.00 Z10.00 E5.00
echo:Auto Bed Leveling:
echo:  M420 S0 Z0.00
echo:Endstop adjustment:
echo:  M666 X0.00 Y-1.98 Z-2.40
echo:Delta settings: L<diagonal_rod> R<radius> H<height> S<segments_per_s> B<calibration radius> XYZ<tower angle corrections>
echo:  M665 L333.62 R163.92 H345.47 S160.00 B90.00 X-0.03 Y0.22 Z-0.19
echo:Material heatup parameters:
echo:  M145 S0 H180 B50 F255
echo:  M145 S1 H215 B55 F255
echo:PID settings:
echo:  M301 P23.47 I2.06 D66.81
echo:  M304 P168.21 I27.38 D258.37
echo:Z-Probe Offset (mm):
echo:  M851 Z-0.05
echo:Stepper driver current:
echo:  M906 X 800 Y 800 Z 800 E0 800
echo:SD init fail
echo:endstops hit:  X:290.57 Y:290.57 Z:290.57

[dembach]

Also another bug was removed by that.....
initially i needed an extra reset after applying power to the System.

now it is booting perfectly... without need of any extra reset as before.
really good work....

should we close ?

[Bob-the-Kuhn]

Thanks for testing. Really glad to see it's working for you.

I'll close it.

[Bob-the-Kuhn]

@dembach

I was checking on my V2.1 order & I ended up chatting with the supplier directly. He mentioned that he'd like to build something newer than the 2.1 & I remembered that you had built a 2.2.

If you don't mind, please send a pointer to the 2.2 files to [email protected]

Looks like my V2.1 will be here in 6 weeks. He still has to build it!

@cjsoong - I used your link to order my 2.1

[tig33r]

@Bob-the-Kuhn @cjsoong also ordered one on taobao but supplier suprisingly delay shipping.......

[Bob-the-Kuhn]

@cjsoong - send an email to [email protected] with your order number to be sure he has your order.

I just chatted with the builder/supplier tonight. He still needs to build the boards. He's planning to ship in a month.

[yyf2009]

@dembach Do you have a V2.2 design file? I did not find it in @bobc's repository
-----I am a supplier from China

[tig33r]

https://github.com/bobc/RAMPS-FD/tree/dev/RAMPS-FD this one?

[yyf2009]

@tig33r think you

[yyf2009]

@bobc why the R1003 is 1.8k? Instead of 1.5k? If U1001's reference voltage is 1.24v, then its model should be TLV431 instead of TL431.

Looking forward to your reply my E-mail:[email protected]

[rafaljot]

@cjsoong, @yyf2009 how did you connect termistor and what thermistor table do you use?
It looks like this issue from v2a is still unresolved
https://github.com/bobc/bobc_hardware/blob/master/README.md
"incorrect thermistor readings. The ADC protection cicuit interferes with readings. This can be fixed by removing ADC proteection components."
Agasfer confirmed this workaround works for him:
https://reprap.org/forum/read.php?13,724330

In room temp I see -20'C (minus)... and when I heat it 10'C it increases ~1'C
RAMPS-FD v1 rev. A works correctly in this same configuration.

[cjsoong]

@rafaljot My RAMPS FD board is V2.1
configuration.h thermistor table =51 or 55 (pullup 1K)
configuration.h thermistor table =1 or 5 (pullup 4.7K)
Do you need to make sure that the Pullup resistance on your board is 1K or 4.7K?

[rafaljot]

My is 2.1 too.
R301 is 1K, R504 is 4.7K
OK 51 table works better. Thank you.

[rafaljot]

(this is OT but this thread from beginning is rather generally about RAMPS-FD than I2C_EEPROM.)

finally I made own thermistor table for RAMPS-FD 2.1 and typical NTC 10K 3590 thermistor. It is for Repetier but it is easy to convert for Marlin.

I checked values using pot with oil :D and thermocouple.

#define NUM_TEMPS_USERTHERMISTOR0 34
#define USER_THERMISTORTABLE0 {{1*4,400*8},\
{77 * 4,310 * 8},\
{87 * 4,300 * 8},\
{98 * 4,290 * 8},\
{111 * 4,280 * 8},\
{126 * 4,270 * 8},\
{147 * 4,260 * 8},\
{172 * 4,250 * 8},\
{195 * 4,240 * 8},\
{225 * 4,230 * 8},\
{260 * 4,220 * 8},\
{294 * 4,210 * 8},\
{332 * 4,200 * 8},\
{375 * 4,190 * 8},\
{420 * 4,180 * 8},\
{470 * 4,170 * 8},\
{530 * 4,160 * 8},\
{600 * 4,150 * 8},\
{680 * 4,140 * 8},\
{751 * 4,130 * 8},\
{801 * 4,120 * 8},\
{843 * 4,110 * 8},\
{879 * 4,100 * 8},\
{912 * 4,90 * 8},\
{940 * 4,80 * 8},\
{966 * 4,70 * 8},\
{982 * 4,60 * 8},\
{995 * 4,50 * 8},\
{1003 * 4,40 * 8},\
{1010 * 4,30 * 8},\
{1016 * 4,20 * 8},\
{1020 * 4,15 * 8},\
{1021 * 4,0 * 8}}

[boelle]

For those that are interested in giving Ramps FD a helping hand to become more widely known have a look here:

https://github.com/bobc/bobc_hardware/issues/34

[bruce356]

@Bob-the-Kuhn did you receive the RAMPS FD V2.1 from China https://item.taobao.com/item.htm?spm=a230r.1.14.107.524345baMkb6Zj&id=544866465374&ns=1&abbucket=15#detail
is it safe to use and does it work with Marlin v2 dev
thanks and regards - bruce

[boelle]

it depends if they have put good parts on it that has the correct rating and that can stand the use of that rating... what i mean is that it does not help if the connectors are rated high enough but can only stand use half the rating... ie bed connector is rated for 15A but melts at arround 6/7 A

V2.1 is not the latest, that is V2.3... it should be "safe", source files can be found here: https://github.com/bobc/RAMPS-FD/tree/dev/RAMPS-FD

[boelle]

i would question this seller thou, 2 reasons

1) he does not seem to know what he is selling, why put ramps 1.4 in the title?
2) at ~19 US$ i would question the parts, remember the golden rule: you get what you pay for

[bruce356]

@boelle, I gather you do not actually have one of these cards so are unable to provide an answer to my query.

_"Arduino due ramps_fd v2.1 expansion board (ramps1.4 upgrade)"_

It is an upgrade to a ramps1.4.
I do not see anywhere the possibility of purchasing a finished v2.3 or v2.2 board.

I asked @Bob-the-Kuhn because presumably he has one and can provide an opinion, if he so wishes.
Thanks for your reply and I appreciate you are attempting to promote the RAMPS-FD, but with so many other 32 bit options available it may never take off, especially considering no one is selling them.
regards - bruce

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.