I'm a newbie on marlin firmware, but today, after many readings, I've started a new branch for the JGAurora A5S A1 board (board/jgaurora_a5s_a1).
I have compiled the firmware with the basic configurations, but after the upload it remains fixed on the progress bar and does not restart (as opposed to the original firmware).
The idea is to be able to communicate with the new firmware before correctly compiling the configuration files, but I do not know if it's the right way.
Any suggestion is welcome
P.S. in Configuration.h use: #define MOTHERBOARD BOARD_JGAURORA_A5S_A1
to update the STM32F1 HAL on linux it was necessary to run the following command:
pio update
I created the initial version of the pins_JGAURORA_A5S_A1.h looking at the Dlion/pins.h file of the original source code.
This night I realized that dropbox shows me the original "Doc/02. Development environment description.txt" file with the correct charset, so I used the google translator and got the file that I attach.
There is a lot of information ... I hope to deepen and make further tests soon
Spent a lot of time looking into this this weekend, lost a lot of wasted hours troubleshooting due to a dodgy ST-Link... waiting on a new adapter now. Ideally would be good to get a bootloader integrated to allow flashing over USB from a computer, because presumable we will lose the ability to flash via SD with a new firmware.
Sounds like @jelot_it made some great progress! Looking forward to trying things out soon.
managed to get arduino code running on the A5/A1 motherboard, working serial port etc.
having trouble getting marlin 2.0 to load successfully
very likely that installation will require opening the case, at least for the initial installation
likely that installation will require a ST-Link - they are $4 on ebay, I recommend anyone who is remotely interested in custom firmware down the track to buy one.
The "download" port on the motherboard contains a JTAG SWD interface, but the pinout is completely non-standard. this will help anyone who wants to flash:
Connect this port up to an ST-Link V2
using jumper wires / dupont
cables, and you will be able to backup and upgrade the firmware on the A5S
& A1.
EDIT: I had 3.3v and ground mixed up... rookie error! Diagram above corrected now.
Finally, the jgaurora firmware has two parts - there is a bootloader which starts up first, and then loads the main firmware. The firmware bin files that JGAurora provides are just the second part. The bootloader part remains untouched during updates. I've attached the bootloader - it just needs the firmware appended to be flashed via the ST-link, enabling you to go back to stock firmware without any worries.
The bootloader is responsible for loading the firmware file off the SD card, and for performing the flash-in-place.
The main firmware has a feature called "update fonts" and "update pictures" that loads other files from the SD card and flashes them to the secondary flash chip on the motherboard.
There is also a small third EEPROM on the motherboard, which stores the serial number and model of the printer.
Awesome - I'm going to try to figure out an accurate pinout tonight. I tried to flash the MKS robin (which uses the same CPU) example provided with marlin, using Platformio, but the upload doesn't seem to boot Any progress in that area would be supurb!
Oh man... I just realised you had already figured out the CPU pinout ... and posted it 12 days ago in your github. Looks like I did it the hard way... DOH!
I have also committed the configuration files for the A5s and the A1, but they are minimal configured (just to take advantage of the correct pin file).
- with the printer turned off and not connected to the PC, insert the sd into the printer
- connect the printer to the PC via USB
- when the progress bar is 100%: disconnect the printer from the pc and remove the sd
- open the printer and disconnect the flat cable of the LCD monitor
- close the printer, connect it to the PC via USB and turn on the printer
- now you can send commands via pronterface
be careful because the configuration.h file is not configured, so the motors will move in the wrong way.
is needed to disconnect the LCD monitor or communication with the PC will not work.
I will try to see if I can solve the problem with the connected lcd monitor, so for now I will not modify the configuration files further ... if someone wants to do it: clone the repository and proceed
I finally (FINALLY!!) got a working build too, but there is something wrong with the temperature reading, so it resets almost straight away... but if you connect a serial monitor you will see there is some output :-P
I modified the python script for the MKS Robin to allow flashing of the full firmware via ST-Link:
put jgaurora_ax.py in /Marlin-bugfix-2.0.x/buildroot/share/PlatformIO/scripts
put jgaurora_ax.ld in /Marlin-bugfix-2.0.x/buildroot/share/PlatformIO/ldscripts
put jgaurora_bootloader.bin in /Marlin-bugfix-2.0.x
I pushed a new commit that solve the need to detach the LCD cable... so I could flash the printer and talk with it (without open the printer) with this steps:
These are the only changes I made so far to what you have
in pins_JG.h:
//
// LCD Pins
//
#define FSMC_CS_PIN PD7
#define FSMC_RS_PIN PG0
in configuration.h:
//
// MKS Robin 320x240 color display
//
#define MKS_ROBIN_TFT
Also noticed filament diameter set to 3mm in your conf.
I suspect what we're seeing with the dodgy bed readings could be due to allocating the wrong ADC (1, 2 or 3) to the correct pin (PC2) - perhaps its trying to read the ADC to two pins at the same time. I'm not sure how to change that - its stumping me. I was able to create a simple Arduino sketch to confirm the pin is correct, but I had to compile it against the official ST STM32 HAL so I could use the pin name, whereas we're using the community maple based STM32 HAL for Marlin. I reckon migrating to the official HAL would be a good goal to set.
void setup() { Serial.begin(115200); }
void loop() {
int sensorValue = analogRead(PC2);
Serial.println(sensorValue);
delay(1); // delay in between reads for stability
}
I think what I might be seeing with the dodgy LCD could be due to a mismatch in set speed somewhere?
in the last commit I have defined the FSMC_RS_PIN as:
#define FSMC_RS_PIN PF0
the value PF0 is the default value taken from the translated documentation and from the file ./Marlin/src/HAL/HAL_STM32F1/u8g_com_stm32duino_fsmc.cpp (alias FSMC_RS_A0)
I got that PG0 from mapping the RS pin (labelled on LCD PCB) to the CPU pin on the motherboard. Sounds like initialisation of the LCD is a pain because the controller can vary - but it also sounds like we can take advantage of the fact that the controller is initialised by the boot loader!
I think the problem with the bed readings may be a ADC pin configuration problem - not that we have selected the wrong pin, but that we have not correct assigned one of the three ADC's to that pin. I think the file we need to change is ~\.platformio\packages\framework-arduinoststm32\STM32F1\variants\generic_stm32f103z\board.cpp
The question is.... I don't know what the change is that is required.
yesterday I made a last commit with the modified Configuration.h files (I took the data from the original code, but probably will be re-edited).
I deliberately left the bed turned off, but be careful because not reading correctly the temperature value, the extruder immediately heats up
the file ~\.platformio\packages\framework-arduinoststm32\STM32F1\variants\generic_stm32f103z\board.cpp seems correct to me
I think we should act on the Marlin/Marlin/src/module/temperature.* files (maybe in the Temperature::analog_to_celsius_hotend and Temperature::analog_to_celsius_bed functions)
maybe on marlin we do not use the same samplerate, but I think our problem may be the division by 4 made in the pin file:
#define TEMP_0_PIN (Get_Adc(ADC_Channel_12)>>2) // the >> 2 #define TEMP_BED_PIN (Get_Adc(ADC_Channel_11)>>2) // the >> 2
we probably need to have a custom conversion ... the thermistor used in the source code looks identical to what we set up on marlin (the 1 value [1 : 100k thermistor - best choice for EPCOS 100k (4.7k pullup)])
Now I have to go to work. I'll do some tests tonight
When I tested reading from the bed thermistor port on my own program, I had no problems. What I’m wondering is if because were using both the nozzle thermostat and the bed thermistor on ADC1 (just on different channels), whether that might be causing the problem because? I was wondering if we have to move ADC1 to ADC2 for the bed readings, and use ADC1 just for the nozzle readings.
I thought the operator >> is a bit wise shift to the right, so it’s only divide by 2, not 4?
I thought the operator >> is a bit wise shift to the right, so it’s only divide by 2, not 4?
shift to the right of N position, so it make a division for 2^N i.e. 16 is 00010000 in binary notation... 00010000 >> 3 = 00000010 = 2 in decimal notation, so we have divided for 2^3
I deepened a bit the "road" of division, but in reality this is done in the Marlin/src/HAL/HAL_STM32F1/HAL.cpp file (@see HAL_adc_start_conversion function)
I was wondering if we have to move ADC1 to ADC2 for the bed readings, and use ADC1 just for the nozzle readings.
honestly I do not know and at the moment I have no ideas... today I get the stlink cable purchased, if I understand how it works I try to do some debugging.
P.S. I have enabled the: #define SHOW_TEMP_ADC_VALUES in the Marlin/Configuration_adv.h file, but when I try to run the M105 command I do not see the raw value... I have to enable something else?
Ok, I think I give up. I am really stumped about this LCD.
The only clue I found is, that the distortion is mostly resolved when I
connect any two of the data pins e.g. connect DB5 (PE7) and DB6 (PD1) on
the LCD. Very odd! See the photo below.
I think the issue is the hold time. I can't figure how to change the ADDHOLD timing. I tried changing the FSMC_ADDRESS_SETUP_TIME and FSMC_DATA_SETUP_TIME in the STM32F1 HAL file: "u8g_com_stm32duino_fsmc"
Comments
The idea is to be able to communicate with the new firmware before correctly compiling the configuration files,
but I do not know if it's the right way.
Any suggestion is welcome
P.S. in Configuration.h use: #define MOTHERBOARD BOARD_JGAURORA_A5S_A1
There is a lot of information ... I hope to deepen and make further tests soon
Connect this port up to an ST-Link V2 using jumper wires / dupont cables, and you will be able to backup and upgrade the firmware on the A5S & A1.
The bootloader is responsible for loading the firmware file off the SD card, and for performing the flash-in-place.
There is also a small third EEPROM on the motherboard, which stores the serial number and model of the printer.
Thanks for all the information you have shared.
Any progress in that area would be supurb!
Probably the MKS robin firmware does not work because it is encrypted (@see Marlin/buildroot/share/PlatformIO/scripts/mks_robin.py file).
I will try to see if I can solve the problem with the connected lcd monitor, so for now I will not modify the configuration files further ... if someone wants to do it: clone the repository and proceed
void setup() { Serial.begin(115200); } void loop() { int sensorValue = analogRead(PC2); Serial.println(sensorValue); delay(1); // delay in between reads for stability }the value PF0 is the default value taken from the translated documentation and from the file ./Marlin/src/HAL/HAL_STM32F1/u8g_com_stm32duino_fsmc.cpp (alias FSMC_RS_A0)
your PG0 comes from?
I deliberately left the bed turned off, but be careful because not reading correctly the temperature value, the extruder immediately heats up
the file ~\.platformio\packages\framework-arduinoststm32\STM32F1\variants\generic_stm32f103z\board.cpp seems correct to me
I think we should act on the Marlin/Marlin/src/module/temperature.* files (maybe in the Temperature::analog_to_celsius_hotend and Temperature::analog_to_celsius_bed functions)
I thought the operator >> is a bit wise shift to the right, so it’s only divide by 2, not 4?
shift to the right of N position, so it make a division for 2^N
i.e. 16 is 00010000 in binary notation... 00010000 >> 3 = 00000010 = 2 in decimal notation, so we have divided for 2^3
honestly I do not know and at the moment I have no ideas...
today I get the stlink cable purchased, if I understand how it works I try to do some debugging.
P.S. I have enabled the: #define SHOW_TEMP_ADC_VALUES in the Marlin/Configuration_adv.h file, but when I try to run the M105 command I do not see the raw value... I have to enable something else?
Howdy, Stranger!
RegisterIt looks like you've been lurking for a while.
If you register, we will remember what you have read and notify you about new comments. You will also be able to participate in discussions.
So if you'd like to get involved, register for an account, it'll only take you a minute!