darkspr1te / mksbootloader

A fork of my vanilla bootloader but with tft control
1 stars 1 forks source link

Need help...Bricked MKS TFT 35 v1.0 #1

Open bthome opened 4 years ago

bthome commented 4 years ago

I tried to flash the wrong OS firmware and I bricked the thing. I still get a blue light, I did go through your guide and was able to erase flash and uploaded new bootloader\firmware but it still is blank. I don't think I have an appropriate set of files to get me to a proper boot up. I'm willing to go back to stock if I could find it. Any help you could provide or point me to a set of files that I can try to flash would be greatly appreciated.

Thanks. B.

darkspr1te commented 4 years ago

MKS have just released all the files, I have not had chance to go through them fully but there is enough info to port the bootloader to your device. Are you to provide some pictures or links to confirmed pictures of your device too, Another user has ported my bootloader to the v1 28tft which uses the same screen init as mine but the 3.5" and 7" use totally different init sequence for the screen. I would be willing to port it if I can get more information on the screen and it's pinouts (high res pic are enough for that )

bthome commented 4 years ago

Thank You. I hope this helps. You can see in the picture I connected to the Aux-1 port to get to FlyMCU and flash the bootloader (bricked it). I just have a blank screen so there is nothing visual except the blue LED when plugged in. Let me know if there anything else you need. I'm on standby to help debug or test any solutions you can come up with.

IMG_0038 IMG_0039 IMG_0040 IMG_0041 IMG_0042 IMG_0043

darkspr1te commented 4 years ago

According to the flymcu screenshot it's a F40x cpu, all of my stuff was for f10x , so that complicates it quite a bit. Only as far as bootloader goes, i know my code in base for wont work with f40x as all the inits are specific , not sure how to proceed , let me see if i can find some F40x init code, i might be able to port my bootloader as i made sure it was based on stm32cube/platformio for that reason. this means that the init of the chip changes (stm32cube will spit out that for us so long as we same some basic details like which pin spi is on , xrystal speed etc) but the flash code does not as thats cube based HAL HL , that does not mean we dont face problems, darkspr1te

bthome commented 4 years ago

Appreciate any help. I hope that MKS publishes their bootloader now that they have published their other code. Not holding my breath on that. I can't find anything on google that could get me back to factory. Hopefully someone can publish a backup.

darkspr1te commented 4 years ago

ok, I've started on a basic model to include other devices in the same tree https://github.com/darkspr1te/mksbootloader/tree/features right now it builds, which is a start, i now have to start writing debug bits to test flash on your device. but in theory i've done enough to flash a led and boot factory firmware. no lcd init yet which means black screen but thats coming. am no expert so my method is such i write a lot of test code to wiggle my fingers (or gpio and such in this case) , i do have sources & schematics to refer to but this chip has different init routines and gpio labels and such so some of my code wont work with this just yet.

bthome commented 4 years ago

I pulled the code and setup Platform.io. Was able to build and get an .elf. That's as far as I can get. Let me know if you have some next steps or instructions and I'll try to keep up. I have some development background, been a while, and not really at a device level.

darkspr1te commented 4 years ago

if you can get a elf file then your 100% ready to get involved in the dev side. I'am currently patching the "feature" branch to produce easier to work with files. For example on my side i work with st-link adapter and bin/elf files via openocd where as the flymcu recovery tool uses hex files and is not suited for debugging. I'll push that build today so you can try out the latest hex files right away.

darkspr1te commented 4 years ago

you will find the output files in .bin format and .hex for in buildroot/BOOTLOADER. I will patch the code today so we should get the lcd led light flashing (i still have timing/rcc/clock issues to resolve as well as f10x against f40x differences that change the code totally. )

bthome commented 4 years ago

Thank you. I uploaded the .hex file (see log below) there is a failure so not sure if this was during or after the upload. What firmware should I be putting on the SDCard the MKS or BIQU firmware? Are we to that point?

DTR be High(+3-+12V),Reset RTS be High(+3-+12V),enter ISP ...Delay 100ms DTR be Low(-3--12V),Reset Released RTS keep High Connectting...39, Received:79 1F Connect Ok @COM3@115200bps,@8359ms BootLoader Version:3.1 PID:00000413 STM32F40xx_41xx OptionBytes readout: FFAA0055FFAA0055FFFF0000FFFF0000 Start Erase Chip,There will be a long time to Erase,wait please! FULL chip erase Ok!!! Start Disable Write Protection Write Protection Disabled!!!Full Erased!!! DTR be High(+3-+12V),Reset RTS be High(+3-+12V),enter ISP ...Delay 100ms DTR be Low(-3--12V),Reset Released RTS keep High Connectting...89, Received:79 1F Connect Ok @COM3@115200bps,@19344ms BootLoader Version:3.1 PID:00000413 STM32F40xx_41xx OptionBytes readout: FFAA0055FFAA0055FFFF0000FFFF0000 @19485ms,Ready for Program Write 25KB Ok,100%,@62297ms Write Option Bytes: FF AA 00 55 FF AA 00 55 FF FF 00 00 FF FF 00 00 Write Option Bytes Ok OptionBytes JustWrited: FFAA0055FFAA0055FFFF0000FFFF0000 Go from 08000000 Failed...Maybe Writed OptionBytes just before!!! www.mcuisp.com(Versatile Handy Programmer EP968,World's first):Mission Complete,Anything Ok!!!

darkspr1te commented 4 years ago

sadly the build is broken while i split the startup of the two different devices, it's not even working for original f107 atm, but i will get it all fixed

bthome commented 4 years ago

Any progress?

darkspr1te commented 4 years ago

not at the moment, I have refactored my build system to take into account the rather large difference between the two devices at the source code level & device level. I dont even have a f40x device to test on so am having to pull known working code when i can find it. MKS sources proved useless as they wont mix with the stm32cube backend i use.

iz3man commented 4 years ago

Good that I found that thread. I got exactly the same problem with exactly the same board. I was a bit too adventurous and took a wrong hex file and flashed it to the TFT. It was going to 100% and then stopped and stayed there. As soon as there is a working repair bootloader file i'd be happy if it could be shared. Am I correct, that for programming you just need a "regular" usb/serial adapter connected to AUX1? Looking at the pics above the one wire connected to the JTAG connector is not connected anywhere else right?

iz3man commented 4 years ago

On the other hand I must say that I have really no plan what can be done at present stage. I was under the impression, that BTT firmware is ported to MKS TFTs. Correct? Therefore the MKS needs a) a bootloader that accepts the new firmware b) the new firmware c) pics & font directory

Also correct? What I don't know: Are there precompiled hex/bin files for the MKS TFT35 v1 and for the TFT28 v4? Do they need to be compiled by me, or is the software not ready for those yet? Atm I'm still waiting for the TFT28 to arrive, and as I already bricked the TFT35 i want to be prepared ;)

darkspr1te commented 4 years ago

Good that I found that thread. I got exactly the same problem with exactly the same board. I was a bit too adventurous and took a wrong hex file and flashed it to the TFT. It was going to 100% and then stopped and stayed there. As soon as there is a working repair bootloader file i'd be happy if it could be shared. Am I correct, that for programming you just need a "regular" usb/serial adapter connected to AUX1? Looking at the pics above the one wire connected to the JTAG connector is not connected anywhere else right?

is your unit still going into the bootloader ? does it try to flash the file if it's on the sdcard when booting?

iz3man commented 4 years ago

No. It just stays black

darkspr1te commented 4 years ago

I would like to see if we can read back your flash, theres always a chance we might be able to recover. Using the flymcu app you can read back the flash using a serial adapter. it's possible theres still a bootloader. we can but try

iz3man commented 4 years ago

Ok. Any special version of flymcu to use? And maybe you have a short how to read the flash? I got the serial adapter connected GND VCC TX RX as in the pictures posted here some time back. No other connections. Do I need to set a baud rate?

iz3man commented 4 years ago

No success

image

darkspr1te commented 4 years ago

the device need to be in boot from system memory mode, this means you need to put 3,3v to the mcu side of R10 resistor then power up the device(or reset it via the RST programming pin) , it's located at the top of the PCB next to the mcu(theres a metal tab near it) this will allow the device to boot from software control and not the flash, unless you have a SWD adapter then the only way it to use the devices RAM to store our code(or flymcu code) to read out the flash.

iz3man commented 4 years ago

Thanks. I thought that already after reading a lot about programing of the STM. Just wanted to be sure and have the confirmation of some experienced guys. Will try. Keep fingers crossed 👍😎

iz3man commented 4 years ago

This is the setup. Connected R10 YELLOW (boot0 pin of the STM) to 3.3V RED while pressing RST PINK. 3.3V RED was messured against GND BLACK.

Then I tried to read the Flash and/or ChipInfo, but no response from the Chip. Used a regular FTDI232 adapter with GND/VCC and RX/TX to TX/RX of the AUX-1 port of the board.

image

darkspr1te commented 4 years ago

i will test this on my unit tonight, it should work, has in the past.

iz3man commented 4 years ago

Thanks a lot. And please send FlyMcu settings as well.

darkspr1te commented 4 years ago

You need to use USART1 which is located in the WIFI connecter (either TXD or TX and RXD or RX) as AUX1 is UART3, the Pins are PA9/PA10 on the chip (USART1) and according to the schematic they are routed to WIFI connector. Also I have started a new repo for the 407VET bootloader and test code, https://github.com/darkspr1te/stm32f407_vet_bootloader , right now all it should do is blink the lcd backlight. this is not intended to recover the bootloader but replace it, although its far from doing that yet. It's a start though.

iz3man commented 4 years ago

Thanks. I will try. Maybe those pics above where the serial auf AUX1 was used shoulded be marked as wrong? But why would they have been posted then?? I will try asap and tell you if it worked. Another question: Why don't you publish compiled, ready to flash BIN files? This would take away another source of possible problems. Setting wrong modes or something else will creat a bad firmware file.

iz3man commented 4 years ago

Still no sucess. Connect FTDI Adapter to WIFI connector, connected R10 to 3.3V, pressed RST, and still no response from the chip. Could you please post your FlyMcu setting so i can compare? Thanks!

darkspr1te commented 4 years ago

Well its possible the schematic is wrong, thats all i have to go on right now and a few blurry pictures. I have not published a bin file yet as it's not quite that easy to to build it for a device you cant test on, I did look back at the pictures and I see what you mean, he's connected via AUX-1 lower pins, I might have been wrong on that. Also i have not used flymcu but stm-flash which works fine with my ftdi (this is due to my current setup, normally i use st-link/blackmagic probe for programming and uart for debug). I'll try again this eve, maybe i got it totally wrong.

iz3man commented 4 years ago

The problems start, as this f**** chip has TWO dots on it. So the first issue i had was identifying PIN1. I downloaded the datasheet and there are all pins. It's the 100pin version of the STM. I made sure that i found the correct pins was looking for VSS/GND and check for continuity between those pins. So I'm quite sure I got the correct pins.

You are correct with USART1 and PA10/9 for RX/TX.

image

Bootloader

image

Not sure what that really means:

image

image

image

iz3man commented 4 years ago

I just looked for CC between pins on the board and the STM itself. Turned out that neither TX/RX of AUX1 nor WIFI were directly connected to PA9/10, but TXD and RXD of WIFI are connected to PA9/10. So those should be the correct pins to connect to.

bthome commented 4 years ago

The method I used above seemed to work for me. It went through the process to delete the firmware and when I went to upload it incrementally wrote the firmware (0-100% written). Now I can't tell you if it wrote it and where, I'm not sure what the appropriate FlyMCU settings should be. I suspect the bootloader is messed up so flashing the firmware doesn't seem to make a difference. I'll send you screenshots if you need additional verification or if any screens will provide more clues.

iz3man commented 4 years ago

Thanks @bthome. So you confirm that you had the serial adapter connected to AUX1 ?? Strange, as those are not connected to the STM directly. I also suspect the bootloader to be broken now. Hopefully @darkspr1te can find a solution.

bthome commented 4 years ago

I tried everywhere there was an RX\TX (including the WiFi) and didn't get any response from FlyMCU. I was able to get acknowledgment from the RX\TX on the Aux1 port. It seemed like it uploaded the firmware, however all I get is a black screen (blue LED). I hope we can find a resolution, otherwise I will just throw this board on the stack of trial\error collection I have. :-)

iz3man commented 4 years ago

But reading what you posted some time ago, it seems that you somehow succeded to communicate, get an answer from the board and upload some data. Here, the TFT seems to have a crashed bootloader so doesn't reply at all, but I was expecting to be able to upload w/o bootloader when you connect to the CPU?!?

darkspr1te commented 4 years ago

Here's another posible solution, Using the FTDI adapter and openocd together you can connect to the SWD port and dump the firmware. I've not tried this but I do know the ftdi chips and openocd do support swd. https://plaes.org/technotes/embedded-systems/ftdi-ft232h-for-hardware-hacking/

iz3man commented 4 years ago

I got an ST-Link V2. Would that help? Just trying to find out if I can connect it to the TFT.

darkspr1te commented 4 years ago

yes, in fact the stlink adapter is perfect, you can connect to the jtag port next to the wifi port , you can then dump using many stlink utils. I personally use st-link official tool as well as openocd to dump st chips when needed. https://www.st.com/en/development-tools/stvp-stm32.html

iz3man commented 4 years ago

Good to know. Do you have a pinout of the JTAG header? Or is this standardized somehow? I can't find it. If not I still can see which CPU pins are connect to the JTAG header. But which PINs of the CPU do need to be connected to what PINs of the ST-Link? Thanks!

iz3man commented 4 years ago

image

darkspr1te commented 4 years ago

on the stlink you will have GND,5v,3.3v , swd, swclk . connect SWD to pin 1, swclk to pin3 and gnd to gnd.

iz3man commented 4 years ago

Seems to work SOMEHOW. Connected the ST-Link to the TFT. Installed "STM32 ST-Link utility". Open the firmware.bin file, and went to "Target" "Program & Verifiy". This is the output:

15:17:52 : ST-LINK SN : 51FF6C064882575026511387 15:17:52 : V2J17S4 15:17:52 : Connected via SWD. 15:17:52 : Connection mode : Normal. 15:17:52 : Debug in Low Power mode enabled. 15:17:52 : Device ID:0x413 15:17:52 : Device family :STM32F405xx/F407xx/F415xx/F417xx 15:17:53 : Can not read memory! Disable Read Out Protection and retry. 15:18:18 : [firmware.bin] opened successfully. 15:18:18 : [firmware.bin] checksum : 0x00079472 15:18:41 : Read out protection is activated. 15:19:01 : Read out protection disabled. 15:19:02 : Memory programmed in 0s and 750ms. 15:19:02 : Verification...OK 15:19:02 : Programmed memory Checksum: 0x00079472

Looks like it was programed and verified OK, but you mentioned it should "BLINK" ?? Nothing's blinking here.

iz3man commented 4 years ago

Did i bit-comparison as well, and it looks as everything was programmed correctly?!

image

iz3man commented 4 years ago

Now I'm quite confident that I did everything correct. I even compiled your "v35 bootloader test firmware" a second time with platform.io and compared this to the memory of the STM32 on board, and it's totally fine. But still it shows a BLACK SCREEN only. Nothing else. But still I'm happy how far we came. At least I can now program the display in case something else goes wrong. I'm waiting for a smaller TFT28 in the mail (as it will be a perfect match for my ender2) and it's always good to know that you got a safety net in case something goes wrong.

darkspr1te commented 4 years ago

Now I'm quite confident that I did everything correct. I even compiled your "v35 bootloader test firmware" a second time with platform.io and compared this to the memory of the STM32 on board, and it's totally fine. But still it shows a BLACK SCREEN only. Nothing else. But still I'm happy how far we came. At least I can now program the display in case something else goes wrong. I'm waiting for a smaller TFT28 in the mail (as it will be a perfect match for my ender2) and it's always good to know that you got a safety net in case something goes wrong.

Couple of questions, what Time zone are you in? do you have a discord? I will be updating the code tonight, the reason it's not blinking is I forgot to INIT the GPIO fully, this will happen while am finding my feet on a new chip(most of all one i dont have in front of me)

darkspr1te commented 4 years ago

I just re-read you original log for writing, It seems that MKS activated CROP (code read out protection) on your model, that explains why others were no able to dump the firmware using normal access. This was not present on the 25/32" models as i've checked the two i have that are untouched. There still is a way around this for devices that still boot but not for other devices. I guess i will have to complete the 407 boot-loader regardless.

iz3man commented 4 years ago

Central Europe, Disord ID izeman #3770 And yes, i noted that as well. It was locked for READING. But it's unlocked now, and can be accessed.

darkspr1te commented 4 years ago

ok, i've pushed a updated one with full gpio init. it should now blink.

iz3man commented 4 years ago

Should. But it doesn't :( TFT just remains black (not backlight on - nothing)

iz3man commented 4 years ago

Couple of questions, what Time zone are you in? do you have a discord?

Sent you mine, waiting for your add. What's your tag and what time zone are you in?

darkspr1te commented 4 years ago

Couple of questions, what Time zone are you in? do you have a discord?

Sent you mine, waiting for your add. What's your tag and what time zone are you in?

apologies, been overwhelmed by work (no rest for the IT staff ) , my time zone is +2 gmt so should not be issue for a evening chat on discord. my id is darkspr1te #2605 , have sent f/request. As for the no blink, um , dunno, I used the sources provided by MKS for the gpio init , if we are not getting that then I can only assume it's not getting to that point in the code. this build does not have my Core dump code in it yet, that code should dump the error to serial port 1(USART1) , i will try and integrate that part soon.