Hi,

recently i´ve aquired a Creality CR100 (not 10 - yes, the "kids toy") and i am in the process of heavily modifying it, including adapting a more recent (the actual) Version of Marlin to it.
It was already running Marlin from factory, but idk which Version, i suppose it was one which used Maple as the main Environment.

Nevertheless, i have strong Problems to get the original OLED-Display working or any other I2C Display, which is connected to PB10/PB11 (I2C2) of the STM32F103RET6 MCU,
and i have no clue where to look at.Originally i wanted to replace the OLED-Display with an HD44780 on a PCF8574 I2C-IO-Expander.

I2C2 seems a bit uncommon, but I2C1 is used for other purposes (Stepper). The Mainboard itself is a stripped down Version of the "usual" Creality-Boards, consisting of 4*A4988, but is missing
Parts for PWM Fan Control, Heat Bed, has no external EEPROM and uses a different Pin for the Nozzle Thermistor. It has an SD Card Slot, CH340 for USB Serial communication and so on, but for the Display and control Buttons
it differs to the usual Boards (it uses threee buttons for controlling and i suppose they simply sending out a GCode to the Marlin core if pressed)

I´ve adjusted configuration.h, configuration_adv.h and pins_creality_v4 to my needs, leaving config.ini untouched and unused, and i was trying to use U8GLIB_SSD1306 and LCM1602, giving for experimental purposes even stm32f1.ini even the following build-flags (yes, i´ve upload it directly without Bootloader to 0x8010000 via USB Serial & ST-Loader-Demonstrator)

"
#
# Creality 512K (STM32F103RE)
#
[env: STM32F103RE_creality]
extends = STM32F103Rx_creality
board = genericSTM32F103RE
board_build.offset = 0x10000
board_upload.offset_address = 0x08010000
build_flags = ${STM32F103Rx_creality.build_flags} -w -DPIN_WIRE_SCL=PB10 -DPIN_WIRE_SDA=PB11
"

Currently i´m using VSCode and PlatformIO, no Maple environment.

At least i can connect to the board @250KBaud, but no Display activity can be seen, even my Logic analyzer shows no activity on I2C2.

The .pio Build Folder includes (besides Libservo, LibSPi and so on), LibWire and LibU8GHAL. I have an ST-Link Debugger and currently i am in the process of debugging the ELF-File via STM32CubeIDE (which takes a long time because i can only single-Step through it) but i am not absolutely sure if the final Build includes Libwire and LibU8GHal, because i cannot see those Source Files being loaded in CubeIDE.

Any help would be greatly appreciated - i am finally out of knowledge.... even asking Creality a dozen Times led to no usable result. They won´t give out anything yet. The thing is: It -was- originally running Marlin, but idk what
has changed in between. Maybe its also a PlatformIO/Maple issue... i have to original Creality Firmware in .bin-Format, but debugging the disassembled code on a simple Cortex M3-Simulator is a nightmare.

Greetings
Stef

Edited 5 time(s). Last edit at 01/11/2023 04:01PM by stef123.

What OLED display(s) have you tried enabling in configuration.h?

Please post your pins_creality_v4.h file.

#define UART3_TX_PIN PB10 // default uses LCD connector
#define UART3_RX_PIN PB11 // default uses LCD connector


So firstly make sure that your not using serial port 3 for anything


This is the code in PeripheralPins.c for genericSTM32F103RE

//*** I2C ***

#ifdef HAL_I2C_MODULE_ENABLED
WEAK const PinMap PinMap_I2C_SDA[] = {
  {PB_7,  I2C1, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, AFIO_NONE)},
  {PB_9,  I2C1, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, AFIO_I2C1_ENABLE)},
#if defined(STM32F103x || defined(STM32F103xE) || defined(STM32F103xG)
  {PB_11, I2C2, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, AFIO_NONE)},
#endif
  {NC,    NP,    0}
};
#endif

#ifdef HAL_I2C_MODULE_ENABLED
WEAK const PinMap PinMap_I2C_SCL[] = {
  {PB_6,  I2C1, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, AFIO_NONE)},
  {PB_8,  I2C1, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, AFIO_I2C1_ENABLE)},
#if defined(STM32F103x || defined(STM32F103xE) || defined(STM32F103xG)
  {PB_10, I2C2, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, AFIO_NONE)},
#endif
  {NC,    NP,    0}
};
#endif

Note how you need HAL_I2C_MODULE_ENABLED to enable i2c functionality

also note it needs STM32F103xE to enable pins PB10,PB11 as i2c

So try adding
-DHAL_I2C_MODULE_ENABLED and -DSTM32F103xE to the build environment

Edited 2 time(s). Last edit at 01/12/2023 04:24AM by Dust.

Thank you, but unfortunaly the same issue.

With the additional Build Flags the compiler complains about a redefinition of HAL_I2C_Module_Enabled, so it seems to be already defined.

What i haven´t told so far: At least with a defined U8GLib_SSD1306 i cannot connect to the board, so its stuck somewhere. U8GLib removed
- no connection issue, but of course no screen. Afaik U8GLIB could be used with I2C or SPI, so the question is which Interface is assigned
to U8GLIB at build time.

This is where i have as a non C++-Coder (only Assembly) the most problems. If one or more interface is potentially available, there must be in my
understanding somewhere an assignent which interface could be used for a particular function. As seen in peripheralpins.c - two potential interfaces,
but is it enough to declare the pins at Build Time to PB10/11 in order to automatically switch to and use the second -Hardware- interface and
-if- the Library could be used (or was written for more than one Interface type), where is the decision made which Interface type (or number)
should be used?

Or is the interface automatically switched as soon as the pins of the interface are already used by another function (eg Steppers in this case) -
but if so, who decides about assignment priority?.

Edited 3 time(s). Last edit at 01/12/2023 09:27AM by stef123.

Hm...

with #Show_bootscreen enabled, it jumps to - and is stuck there @ SETUP_RUN(ui.show_bootscreen());

#if BOTH(HAS_WIRED_LCD, SHOW_BOOTSCREEN)
SETUP_RUN(ui.show_bootscreen());
const millis_t bootscreen_ms = millis();
#endif

which triggers the Watchdog:

WWDG_IRQHandler:
0801212c: b.n 0x801212c

with #Show_bootscreen disabled it jumps into the main loop() and no screen output is visible.

Unfortunaly i cannot log the Trace, because STM32CUBEIde doesnt connect to the programmer if it opens by itself a GDB-Server. I have to start it externally in a shell and connect to it, but there
is no log option.

Please forget the issue for now - my machine is dead - short circuit accident, loose +3.3V wire for setting Boot0 accordingly (no jumper on the main board) connected straight i suppose to life wire (housing of the printer was / is cramped) , which also killed my Computer through USB and my ST-Link - well, happy new year, ship happens, as always.


Well,, it might doesn´t make much sense but i could be still able to use a used Non-Silent-Mainboard from an Ender 3 - is sure is too big, but could be run externally with extended cables, but i am not sure about the voltage, since the Ender 3 requires +24VDC and i only could provide +12VDC, but i suppose its mainly because of the heated bed. The CR100 uses normal Creality-steppers.


I also could use from an Easythreed X1 its ET4000V2 Mainboard (also A4988, SD; USB, but at least an unused headbed connector and PWM Fan control - which cannot be used on the CR100, because the Nozzle would melt away its plastic on which it is mounted, it the Nozzle Fan stalls) , but that thing is running only with a 1284P and i suppose i wouldn´t reach the speeds of the CR100-Mainboard.

But at least adapting an usable firmware and extending it would be easier ( i can program and debug AVRs since +25 Years with no problem at all).

Well, well, well.....

Edited 2 time(s). Last edit at 01/12/2023 08:04PM by stef123.

Quote
stef123
Please forget the issue for now - my machine is dead - short circuit accident, loose +3.3V wire for setting Boot0 accordingly (no jumper on the main board) connected straight i suppose to life wire (housing of the printer was / is cramped) , which also killed my Computer through USB and my ST-Link - well, happy new year, ship happens, as always.

(...)

Sorry to hear that, stef! It just shows that DIY is not recommendable to newcomers without guidance. Just imagine if those live-wires would touch your skin or something! Dangerous! I wish you much more luck in this new year. Don't let yourself get dragged down. After all, we humans make mistakes and learn to do it better next time, by carefully analyzing the situation, what went wrong, how to increase work safety, etc etc! Don't let those live wires dangle around, man.

---

Martin Turski, company owner of EirDev

Support me in my duties! Improve the world through scientific accuracy and ingenuity.

Many thanks - i´m not a new-comer :-) I created in the past 30 Years until now several electronics projects (including some which include 220V) , but this was pure accidently. I had to use a DuPont-wire on 3.3V to pull Boot 0 up once at a specific resistor (in order to get into Programming / Debug mode), because that thing doesn´t had a jumper for it - and while the machine was sitting at 90 degree angle and bottom open , the cable extended by itself from top down to the (isolated!) life switch and i -guess- its made the wire contacting life, but it could be also only 12 Volts from anywhere of the Mainboard. I only saw a "certain flash" i nthe corner of my right eye while debugging the issue.

Nevertheless, it killed the machine, the ST-Link and the Computer.

But hey, its Friday the 13th. The clear mistake i made is that i didn´t pull the mainbord out of the shell, as i did before several times. The machine is an "all in one" solution and has the Mainboard, PSU and three Steppers cramped into the botton with not really much space in between. I thought "leave it in there, what else could happen"


But it is no problem at all, i have some spare Computers, the ST-Link was cheap and the CR100 could be fixed aswell with another mainboard. I "only" have to adapt the 1284P Board for it.....where i feel more secure to handle it in terms of knowledge (and programmig abilities). The "new" Board - i guess its a Sanguino-Clone, named ET4000V2, looks by default far more promising than the stripped down Creality-Board.

Edited 6 time(s). Last edit at 01/13/2023 08:05AM by stef123.

The only thing which makes me -very- angry is the fact, that i´ve asked Creality a dozen times about the modifications they have done to the Sourcecode and they never gave an usable answer. If that would have been the case, i would be already finished with my modifications and the machine would be up and running, minus the loss i had.

We all know that they -have- to release the Sourcecode as soon as they use and modify it, but told me that the Creator of this Firmware for that particular Machine was someone else, namely "BiSun". Haha. Creality builds dozens of machines with a "own" Firmware based on Open Source, the mainboard was also stamped "Creality", but the Firmware Creator was -of course- someone else, which vs virtually non existent in that particular industry, only Import&Export-Cooperations, Pharmacy, R&D (complete different industry) are listed in China under that name. @Creality: Less B**bs and more customer support for those who support -you- with their free work would be indeed a step forward.


Nevertheless, the ET4000 Board is up and running, can handle the steppers and the Endstops, heats the nozzle, but the Display Job & Co still has do be done and i also surely some certain adjustments. But the "new" Mainbaord has to be attached inside - the PSU will find its place externally to get space.

Edited 4 time(s). Last edit at 01/13/2023 04:16PM by stef123.

Well, X/Y/Z/E has been adjusted and that thing prints on the highest speed (everything is set to the possible maximum) quite well,
OLED-Display / I2C SSD1306 with SAV_3DGLCD is up and running fine, but i am struggling with the KY-040 Encoder.
Pin Setup used Sanguinololu_11.h, Controller is 1284P in TQFP44-Format. Right after the Boot Screen the Status Screen is shown.
"Lcd Slim Menus" is defined.

For me as an Assembly programmer which thinks in DDRX, Port.X and Pin.X, the method of Pin Assignment is quite unusual,
so i´m currently struggling with the Pin Mapping fot the Encoder.

My board uses an 12 Pin Aux Header, which seems to be somehow related to the 14-Pin Sanguinololu 1.4 AUX pins (in pins_sanguinololu_11.h),
but not precisely. 12V and Second GND is missing,

Mapping is as follows:


+-------------------------------------------+
|+5 MOSI TX1 RX1 SDA SCL |
|GND SCK AD4 AD3 AD2 AD1 |
+----------------+ +-------------------+



If this mapping is the thing to use:
[imgur.com]

Means, it the Button, which does a Pulldown to GND on Action, is connected to A1, it could be according to the Mightycore Sanguino Number Declaration

#define IS_NEWPANEL 1
#define BTN_EN1 10
#define BTN_EN2 11
#define BTN_ENC 30

or, according to the Numbering Scheme in pins_sanguinololu_11.h

#define IS_NEWPANEL 1
#define BTN_EN1 10
#define BTN_EN2 11
#define BTN_ENC 28


But it doens´t work at all. There is no input pullup active on A1/28/30 (adding an external one makes no difference). Idk if Marlin sets the Pullup accordingly - i guess so- and if Software Sampling or
Pin Change Interrupt for the Button is used - -or- if a "real" configurable HW-Interrupt like INT2 has to be used.

Or my Expectations are wrong and something is missing. Is the Status Screen the first thing that comes up - and the Menu pops up, if the Encoder Button is pressed, or vice versa?

Edited 5 time(s). Last edit at 01/14/2023 08:51PM by stef123.

Works. I also had to define #ULTIPANEL and remove it from the sanity check, otherwise it would complain that i have chosen more than one LCD Option. I thought defining #newpanel and assigning the Encoder-pins would be enough to enable Menu Control.

As i only have the Pushbutton of the Encoder available, is there a way to add a Menu/Submenu-Entry for exiting back to the last or main menu/Info Screen?

Edit: Ah, i have overlook the first entry...

Edited 7 time(s). Last edit at 01/14/2023 11:02PM by stef123.

Hm - it makes me a bit nervous that the Screen output hangs in between the first minute after boot - without Encoder it wasn´t do that. But on serial connection it still responds.

Edited 1 time(s). Last edit at 01/15/2023 01:58AM by stef123.

You must have a custom cable/adapter to be using the SAV_3DGLCD with the Sanguinololu_11.

Per the pins_SAV_MKI.h file, the Marlin signal names are:
SR_DATA_PIN
SR_CLK_PIN
BTN_EN1
BTN_EN2
BTN_ENC
KILL_PIN
HOME_PIN

Per the SAV_3DGLCD schematic, the pins BTN_ENC, KILL_PIN and HOME_PIN are just simple switches to ground. Just about any pull up will do.

Per the SAV_3DGLCD schematic, the pins BTN_EN1 and BTN_EN2 have a 10K resistor in series with a switch to ground. Looks like you'll need a 100K pull up resistor on this pin to get TTL logic levels.

KILL_PIN will halt a print if FREEZE_FEATURE is enabled in configuration_adv.h.

Just defining HOME_PIN results in Marlin injecting the G28 command into the command queue if a print isn't in progress.

The Sanguinololu does have 20K - 50K internal pullups but I don't think Marlin has an easy way to enable them on these pins.

Many thanks for the explanation - i will build a PCB for the OLED and Encoder including pullups..

Works by adding additional Pullups to SCL/SDA (as commonly done). I thought the OLED-Display had onboard Pullups. Maybe it has, but maybe there are insufficent.

But another problem rised up and that is X/Y-Mirroring. If i print for example a hole which should be according to Cura on the right side, it appers on the left side. The Printed part which should be according to Cura on top, is on the bottom.


Setup in Configuration.h:

#define USE_XMIN_PLUG
#define USE_YMIN_PLUG
#define USE_ZMIN_PLUG


#define X_MIN_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.
#define Y_MIN_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.
#define Z_MIN_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.


#define INVERT_X_DIR false
#define INVERT_Y_DIR true
#define INVERT_Z_DIR true

#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1

#define X_BED_SIZE 100
#define Y_BED_SIZE 100


#define X_MIN_POS 0
#define Y_MIN_POS 0
#define Z_MIN_POS 0
#define X_MAX_POS X_BED_SIZE
#define Y_MAX_POS Y_BED_SIZE
#define Z_MAX_POS 80


Uisng Cura or pronterface to control the machine directly results in correct movement of the Bed / Head. Pushing the Y up button in Cura moves the bed away from me, pushing Y down results in moving the bed towards me until it reaches the Y endstop on the bottom of the machine.

Pushing "right" (X+) moves the head to the right, Pushing "left" to the left until it hits the X End stop on the left side of the machine. Homing will occur on 0,0,0.

One thing i know from the old Mainboard Setup was that Homing resulted in positioning the Head on X-MAX Position (100), not X-MIN (after checking the X-Min-Endstop) with Y at the Endstop. When the machine finishes printing, It acts like the old Board, it moves the Bed and head towards the end stops. Fiddling around with X/Y-Home-Dir to 1, inverting Endstops, inverting XY directions and so on will result in mechanical chaos.

But something i have to add: Unlike other machines, the X-Axis-Bar is mounted on the lower half of the machine and the head is facing in Y Up direction. Needless to say this -and all other things regarding movements- is depend from which point you look onto the machine. It was designed in that way so that kids, for which this machine was designed, don´t have access to the head assembly. Of course the first thing i´ve done was to remove the outer shell to get access to the internals from everywhere.

Any suggestions?

Edited 8 time(s). Last edit at 01/16/2023 04:10PM by stef123.

You have the Y direction set wrong. I made that same mistake when I set up my custom built printer which also uses a moving bed..

Set INVERT_Y_DIR to false, set Y_HOME_DIR to 1, disable USE_YMIN_PLUG and enable USE_YMAX_PLUG.

Done that, but the machine starts to hammering onto the Y Endstop. I can´t see in pins_Sanguinololu_11.h where the (sorry) Y-Max-Plug is defined.

#define X_STOP_PIN 18
#define Y_STOP_PIN 19
#define Z_STOP_PIN 20

The Endstop connectors are thee pins and two are +5V and GND and the third one is the Pin Signal. Remember, this is a Sanguinololu Clone, not an original one.

The manual movement and its reaction to the endstops is correct as i had configured it. Y-Inverting wouldn´t be a problem at all (honestly i really don´t know it if this also was a problem before, since the prints came out "virtually" correct), but the main problem is that the Print in X Direction is mirrored..

Edited 6 time(s). Last edit at 01/16/2023 04:26PM by stef123.

Y_STOP_PIN is translated in the file pins_postprocess.h.

#ifdef Y_STOP_PIN
    #if Y_HOME_TO_MIN
      #define Y_MIN_PIN Y_STOP_PIN
      #ifndef Y_MAX_PIN
        #define Y_MAX_PIN -1
      #endif
    #else
      #define Y_MAX_PIN Y_STOP_PIN
      #ifndef Y_MIN_PIN
        #define Y_MIN_PIN -1
      #endif
    #endif
  #elif Y_HOME_TO_MIN

Did you do both disable USE_YMIN_PLUG and enable USE_YMAX_PLUG?

Yep. Done that.

You´re my hero, it works. I was trying to move Y manually and then it started hammering, but homing after starting a print works! Thank you so much !

Edit: Curiosly it won´t hammer again now by using manual movement.

Now i can start to build and print out the Casing for the Display/Encoder.

Honestly, in terms of overall speed i don´t see any big difference between the old and the replacment Board, especially we talk here about an 8 Bit vs a 32 Bit Controller. The 8 Bit Board was pulled from a new (29,95€ including shipment) Easythreed X1, which had a faulty Direct-Extruder-Stepper after roughly 30 Prints - a Stepper which virtually you can´t get anywhere apart from AliExpress, but as a German you don't have access to the corresponding page.

The EasyThreed uses 1:32/1:64 common 24BYJ28-Steppers, but the Stepper for the extruder is a bit different, unavailable anywhere apart from China - and because of the (plastic) Gears inside they will fail "almost instantly". The EasyThreed is also slow because of the high gear ratio and the impulses Marlin has to send out per unit.

But regarding 8 vs 32 Bit - it does not have have to be always faster. ARM-Cores offer some quality regarding mathematical operations in the 32 Bit Area, from which marlin certainly benefits, but they rely on a time consuming load-modify-store-technology.

Edited 6 time(s). Last edit at 01/16/2023 05:10PM by stef123.

FANTASTIC!!

Well, i wouldn´t win a design award with this solution (not with PLA parts printed on 190 mm anyway), but it works. The Drivers have now heatsinks and being cooled by using an air duct. The duct fan uses the PWM-Fan-Channel, because the Fan-Connector with fixed 12V has to be used for the Nozzle fan (which also cools down the printout) and he has to be always on; otherwise the Nozzle assembly would melt away when the Nozzle gets hot. 60 Watts PSU is now external.

I´m happy that i removed (almost) anything that shows brand "Creality", in fact it isn´t one any longer - or at least 50%

Next step will be attaching a Heatbed (the Mainboard already has a connector for a HB and its Thermistor), but it could be a bit complicated to find one in 100x100 Size.

One thing i´d also like to try out is to rise the Z-Axis as high as possible, at least 300 mm. This would of course mean that i need to fasten the Z-Axis too. It might be a bit complicated to find a suitable threaded Z-Axis-rod, because its mounted on the Stepper with a sleeve or something in that direction.

One of the larger steps would be building a new and larger printer, but based on other parts. I have a second Easythreed X1 which could provide the same Mainboard and -maybe- its direct extruder. Since i also have an old Flatbed Scanner, i would try use it for the Y-Axis.

Edited 4 time(s). Last edit at 01/22/2023 10:33PM by stef123.