Switch all enums to be within #defines #5
Conversation
This change allows a user to have, for instance, TEMP_4 and TEMP_BED definied but nothing else. The enums which are not defined move "out", allowing the first ones to take the slots in the enum, and since the array is sized on ADC_PIN_COUNT, we always have the right size data and in order.
|
Forgot to mention - your question about sampling: According to this: https://stackoverflow.com/questions/42168388/stm32f103-adc-sampling-rate, it's approximately every 1us. |
|
Merged. So for 1 temp pin, reads at 500Hz, for 2, at 250Hz, etc. Given that, we can reduce the rate at which we capture ADC reads to just be faster than the highest rate, thats 500Hz or 2mS. Anything faster than that, will update the buffer more often than it's needed by the ISR, Since the ADC is more accurate with larger sample times, we should eliminate some noise from the readings. If I get a chance I will look at changing the sampling speed. There should be something either on libmaple or in the ADC library. |
|
Did you get to test the steppers in the Malyan board? |
|
All you have to do is change the sample rate in the init (and perhaps adjust the prescalar). I'm working on getting the toolchain up and working with the malyan board. It uses a nonstandard bootloader, so I've been making a variant and reverse engineering their crc so I can get their board to accept my rom. Will test tonight to see if I've figured out that part. There's some real weirdness in which their reset vectors are set to values that aren't within the firmware binary's boundaries, and they vary with different firmware updates, so it's not an external function call that I can tell. I'll figure it out eventually. |
|
If you have an st-link, or any other debug probe, why don't you just save and replace their bootloader? |
|
Several of the traces are not present in current revs and I'm lousy at soldering. I'm searching for an early rev main board which has JTAG connectors. Oddly enough, I broke the CRC on the firmware for the V2 easily - it's CCIT Poly, and I brute forced the seed values. |
|
Nice, would you mind explaining me how you did it? I'd like to decrypt the firmware for another closed source board, the Chitu 3d, that also uses an STM32F103, and when I looked at it the vector table was also scrambled. Did you use a tool that will try all seed values against the file? |
|
I spent a lot of time staring at it in a hex editor then made some educated guesses + work from the retargetable decompiler, then wrote a brute force program which calculated the "right" values for two different revisions, telling me I'd probably found the checksum. Where's your firmware? I'll look at it. |
|
BTW, tonight I actually managed to get the ST-LINK soldered to the right traces (I sacrificed a controller board) and discovered that Malyan set the read-protect bit. Result - I have a nice, empty mother board for me to test code on. First tests failed - the board hits an error() call during thermal manager init, but my soldering broke loose so I will have to wait until later this week to test it again. |
|
haha you wiped the firmware? |
|
Yup, I wiped the firmware. I soldered multiple thermisters up to test ADC this time around, it's working. I had code running on the Malyan board this morning, but my test board (which I bought as "bad" and has always run literally hot to the touch) died as I was working on figuring out pins. So now I have to hunt down a new one to get back to work. |
|
I had this theory about the F1 read out protection, but didn't spend much time on it: |
|
That’s pretty much the shell code I’m working on. Read out doesn’t stop code from reading, just JTAG and SWD.
…Sent from my iPhone
On Oct 11, 2017, at 1:46 PM, victorpv ***@***.***> wrote:
I had this theory about the F1 read out protection, but didn't spend much time on it:
So the memory can't be read from outside, but a program running can read the flash and print it out thru serial, usb, whichever way. That is confirmed and is actually within the specs. So if you can load your own code without wiping the bootloader, you can load a piece of code that reads the booloader memory and spit it out.
Additionally, you can write to RAM and run from RAM while the flash is protected, but if a debug probe is connected, then a program will fail and crash if trying to read from flash. But if you load the program to RAM, then set the boot pins to boot from ram, disconnect the debugger, and reboot, the MCU should boot from RAM, and hopefully since the debugger is now disconnected, the program could read the flash and spit it out. So even without knowing anything about the bootloader, you could load the dumper to RAM. I didn't get to test that fully. I did test to load the program to RAM, and see it crashing, but had the debugger connected. Only later I read that when a debugger probe is connected, and read protection enabled, programs can't read from flash.
Whenever I get a chance I'll try to test that further.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
So the plan of attack is simple - both V1 and V2 of this printer do a lousy job of validating their firmware. I found a function that traces a null terminated string in R0 to the display controller, and the plan (once I replace my board) is to patch this code into the firmware update, then listen on the display controller as it reads 128k worth of data one byte at a time and echoes it to the serial port. The only complication is ARM's literal pool making it more difficult to patch this in. |
|
Well, it turned out I was being dumb. The bootloader is nonstandard, but my linker script had the wrong offset. Once I fixed it I was able to load up Marlin on the Malyan/Mini. This week I’ll work out what the pin mappings are and do some real tests on a real printer.
… On Oct 11, 2017, at 1:46 PM, victorpv ***@***.***> wrote:
I had this theory about the F1 read out protection, but didn't spend much time on it:
So the memory can't be read from outside, but a program running can read the flash and print it out thru serial, usb, whichever way. That is confirmed and is actually within the specs. So if you can load your own code without wiping the bootloader, you can load a piece of code that reads the booloader memory and spit it out.
Additionally, you can write to RAM and run from RAM while the flash is protected, but if a debug probe is connected, then a program will fail and crash if trying to read from flash. But if you load the program to RAM, then set the boot pins to boot from ram, disconnect the debugger, and reboot, the MCU should boot from RAM, and hopefully since the debugger is now disconnected, the program could read the flash and spit it out. So even without knowing anything about the bootloader, you could load the dumper to RAM. I didn't get to test that fully. I did test to load the program to RAM, and see it crashing, but had the debugger connected. Only later I read that when a debugger probe is connected, and read protection enabled, programs can't read from flash.
Whenever I get a chance I'll try to test that further.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcUk9ArMdYe7QjB_HIhPLxSMf0lqfks5srSkOgaJpZM4PwrRU>.
|
|
I haven't had much time in the last few days, but I need to send you the link to that Chitu board firmware, in case you can figure out what kind of encryption they used, and finish mapping the pins out. |
|
Sounds good. I don’t know that I’ll be able to figure out much, but I don’t mind looking. I have Marlin running on the Malyan M200 system, but am currently at the point where USB doesn’t initialize (making the printer kind of useless). I’ll hook a logic analyzer to it this week and see where in the setup process it fails, which should tell me where the problem is in the maple USB core.
… On Oct 16, 2017, at 8:52 AM, victorpv ***@***.***> wrote:
I haven't had much time in the last few days, but I need to send you the link to that Chitu board firmware, in case you can figure out what kind of encryption they used, and finish mapping the pins out.
That one shouldn't have much trouble either running Marlin since everything in it is pretty standard other than the diplay, which uses a parallel interface, likely thru the FSMC.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcbMUyDOlrGSBsCxFZEdmEisknbpdks5ss3vAgaJpZM4PwrRU>.
|
|
Don't know if you know all of this, but this is how USB enumeration works. Some boards like the maple mini and others use a transistor controlled by a pin. You can see that in the maple mini schematic. For boards that do not have that, I discovered that setting the DP pin to output pulldown and setting it to 0 for a short time, like a ms, was enough to pull the DP line low and signal the host the usb was disconnected. Then we set the pin back to input mode, and the pullup resistor pulls the line up again, and the host thinks something was connected, does a re-enumeration, and loads the serial driver. |
|
I did know this, but it turned out to be key to me figuring out part of how this works. There is a transistor (I wound up scraping silkscreen to follow them). It’s connected to PB9, which is great, right? Except that the logic seems inverse. PB9 has to be turned on for USB to work at all, you drive it low and then pull it back up or USB doesn’t work at all.
Then, USB works if it’s connected at power up, which is huge, since that means I can disconnect my serial 1 rig from the board.
I think this explains a loop I found in the Malyan firmware - they have a timer running (timer2) and check to see if USB state is connected. If it’s NOT, I suspect they toggle the line and check again after a short delay. if it is connected, the loop does nothing.
Seems kind of backwards, but then again, this board has humbled me. The watchdog option bit is set, so I have to feeding the watchdog during initialization, and the scalar set by the watchdog config code in the HAL doesn’t mean much - the WD continues to run at the predefined rate.
Regardless, this is progress, thanks to your feedback. Since I already created a boards variant for Malyan’s board, I’ll add the wonky init code there instead of Marlin, and figure out an appropriate housekeeping chore to do the line toggle every so often. This means soon I’ll be hooked back to a real printer and can test stepper and endstop ISRs.
… On Oct 16, 2017, at 9:43 AM, victorpv ***@***.***> wrote:
Don't know if you know all of this, but this is how USB enumeration works.
There needs to be a pull up resistor between DP pin and 3V3. That pull up must be connected during communication, and when disconnected it signals the host that the USB device has been disconnected.
On the F103 there is no internal resistor (in the F4 series there is), so there has to be a 1k5 resistor in the circuit between DP and 3v3. Now to switch between the bootloader and the serial port USB drivers, we need to signal the host a disconnect after the main program starts.
Some boards like the maple mini and others use a transistor controller by a pin. You can see that in the maple mini schematic.
For boards that do not have that, I discovered that setting the DP pin to output pulldown and setting it to 0 for a short time, like a ms, was enough to pull the DP line low and signal the host the usb was disconnected. Then we set the pin back to input mode, and the pullup resistor pulls the line up again, and the host thinks something was connected, does a re-enumeration, and loads the serial driver.
Roger perfected that technique and added it to the core, so it is used when you compile selecting a board different than Maple or Maple Mini.
So the Malyan board may be either using a transistor, in which case you should select the board as Maple Mini, but change the USB DISC pin to the one the Malyan uses, or it may not have any transistor and have a pullup straight to 3v3 (like the blupill board does), in which case you need to select a Generic board when compiling, so the code to pull down the pin is used.
Try to trace the USB DP pin in the malyan to find the 1k5 resistor, and then find if thats connected to 3v3, or a transistor. If a transistor, trace which pin controls the transistor.
Easy way for force a re-enumeration if you can trace what the malyin does, is to either remove the 1k5 resistor from the board and use a wired one that you can disconnect and re-connect, or use a lower resistor to pull down the DP line for very short. That should cause the host to think the usb was been disconnected and reconnected and try to discover the device.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcVFWh-FQt0-k_EdpJWcPu10q9akxks5ss4eXgaJpZM4PwrRU>.
|
# This is the 1st commit message: Choose the timer based on MCU defintion. Timer5 is not valid on C8/CB class boards, so use Timer4 for the step timer. # This is the commit message #2: Readme.md update # This is the commit message #3: Readme.md update # This is the commit message #4: Trying to get readme.md updated # This is the commit message #5: readme.md update
This change allows a user to have, for instance, TEMP_4 and TEMP_BED definied but nothing else. The enums which are not defined move "out", allowing the first ones to take the slots in the enum, and since the array is sized on ADC_PIN_COUNT, we always have the right size data and in order.