UP CPU Chip

[upchip]

Didn't know where else to post it, hoped from here it would be useful.

My UP CPU V5 hasn't been properly scratched out and I can make out some of the text.

980 TF TNP 12?? E5P Y9W 58?D8W ??

Might help someone Question marks are where I know there is a number or letter but haven't a clue what they are.

[Gitty-Hub]

Cool, thanks!

[MaikStohn]

Hi,

discovered the CPU type some time ago, the (newer) CPU is:

Tiva™ TM4C1233H6PZ Microcontroller

Is a ARM Cortex M4 from Texas Instruments.

We are working on firmware backup method right now ;-)

[orthoa]

Can't we just load the micro controller with smoothieware now we know what it is? I remember someone saying something similar on a thread about the custom smoothie board for the UP! On Thu, 9 Feb 2017 at 04:35, Maik Stohn notifications@github.com wrote:

Hi,

discovered the CPU type some time ago, the (newer) CPU is:

Tiva™ TM4C1233H6PZ Microcontroller

Is a ARM Cortex M4 form Texas Instruments.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MaikStohn/UP3D/issues/45#issuecomment-278362295, or mute the thread https://github.com/notifications/unsubscribe-auth/ASp3Jjj1vEeCGO8HcrcoZQAJIIIYspmgks5raeDSgaJpZM4LlK-l .

-- Thomas Leahy

Unit 3 / 121 Newmarket Rd Windsor QLD 4030

1800 730 552

[Gitty-Hub]

That is exciting! What could this firmware backup open up? Does it contain a lot of info or options?

[arhi]

any way of easily checking if one has "newer" or "older" cpu, and how to check on mcu what it is? (to test if it's really TM4C1233H6PZ if they have few versions running around

[edbordin]

I stumbled on this thread while researching if I could do exactly what people are discussing here - run open source firmware directly on the original CPU board for the Up! Plus. I'm already planning a couple of simple mechanical mods from the Up! forums but I'd really love to retrofit a bed levelling sensor to it (there's an unused fan port which potentially means a spare GPIO pin). My fallback plan is to use your excellent tools here to move the machine through the 9 bed positions and use a separate USB sensor to take the readings.

@arhi your CPU board should be labelled to identify it. Perhaps @MaikStohn can confirm what their board is labelled as. My old board is labelled "V4.1.1 YL9.091013" and someone has identified it as a TI LM3S5737 (although there seems to be a bit of misinformation on that page, the chip ID seems to be correct based on some initial probing with a multimeter).

Conveniently, the JTAG/SWD pins are routed out to the headers on this old board. So in theory I could start playing with custom firmware straight away, but I'd really like to dump the stock firmware first so I can go back if things don't work out. I'm planning to try to do a flash dump over SWD. If they've configured things properly then the flash blocks containing firmware should have been set as "execute-only" to stop people like me dumping it, but it's worth a shot :D

If anyone has more info, or if I can help in any way, let me know!

TL;DR trying to figure out if I can dump firmware from an Up! Plus.

[arhi]

I'd really love to retrofit a bed levelling sensor to it (there's an unused fan port which potentially means a spare GPIO pin).

where did you find "unused fan port" ?

There is a connector on the back of the board for external leveling sensor. On UP+2 this is connected either to the bed sensor or to the "feeler" that attaches to the head. DOUPTZ is written on that port, it's seen as 4 pin header on the pcb and a 4pin 3mm "banana" connector looking at the back of the board. I wrote about it here: https://www.up3d.com/community/viewtopic.php?t=22192&start=100#p47323

the board schematic related to that connector: https://www.up3d.com/community/download/file.php?id=2481

it goes to 3 pins on the mcu, also one (main) feeler pin goes trough extruder connector all the way up to P2 on the extruder head so you can connect your bed leveling sensor directly on the head, no need to run more cables down to mainboard :D

@arhi your CPU board should be labelled to identify it.

047e3115a V4.7 YL3.130912

My old board is labelled "V4.1.1 YL9.091013" and someone has identified it as a TI LM3S5737 (although there seems to be a bit of misinformation on that page, the chip ID seems to be correct based on some initial probing with a multimeter).

weird, mine has V4.7 (higher) but lower YL I assume mine is older but they changed from V#.# to V#.#.# later you have up plus or up plus2 (this is from up plus2)

Conveniently, the JTAG/SWD pins are routed out to the headers on this old board. So in theory I could start playing with custom firmware straight away, but I'd really like to dump the stock firmware first so I can go back if things don't work out. I'm planning to try to do a flash dump over SWD. If they've configured things properly then the flash blocks containing firmware should have been set as "execute-only" to stop people like me dumping it, but it's worth a shot :D

I hope it should be open since they are using bootloader to upgrade firmware. Also I assume the firmware should be "decodable" from the bin file they used to provide.. anyhow I haven't tried since I moved the the NXP arm myself (running smoothieware)

[arhi]

[arhi]

[edbordin]

where did you find "unused fan port" ?

My Up Plus main board is slightly different to the one on the UP Plus 2. I'll edit this when I get home tonight and add a couple of photos

There is a connector on the back of the board for external leveling sensor.

Unfortunately my board doesn't have this. I've used an UP Plus 2 before so I am familiar with what you're talking about though.

Also I assume the firmware should be "decodable" from the bin file they used to provide..

Hmm, this would be very useful to get my hands on. I was able to get hold of "Up! V1.14" but this did not have any firmware bundled and I couldn't find any earlier versions. You don't mean the *.ROM files do you? Those are just printing parameters rather than firmware. E.g. at one point they released one that enabled .15mm layer height on certain printers. I noticed on the Up3d forums that rather than providing firmware updates, they just provided multiple ROM files that were compatible with different firmware versions. This may be a clue indicating that they've locked down the firmware to make it non-updatable. When I get time and if I'm able to get SWD working I can check how they've configured the flash blocks to confirm if this is the case :/ I'm planning to try using OpenOCD with my raspberry pi.

On the other hand, if this works and I'm able to mess with the firmware we could develop instructions on how to use a super inexpensive pi zero to backup and reflash the board!

edit: Here's a couple of bad quality photos from my phone http://imgur.com/a/v6iye

[arhi]

You don't mean the *.ROM files do you? Those are just printing parameters rather than firmware.

I do :( .. I thought those are firmware, wasn't really looking at the content as I assumed it's firmware :)

I have here bunch of jtag adapters (buspirate, busblaster, MSP430-JTAG-ISO ... ) but I mostly use urjtag and not openocd... update us if you find anything useful :D

[edbordin]

Well, I couldn't connect with SWD. Entirely possible I have OpenOCD configured wrong but I think it's likely they have disabled debug. From the datasheet: "USER_DBG: This register provides a write-once mechanism to disable external debugger access to the device...Once commited, the value of this register can never be restored to the factory default value"

I noticed this "Performing a total of ten JTAG-to-SWD and SWD-to-JTAG switch sequences while holding the device in reset mass erases the flash memory". Also "Performing the sequence below causes the nonvolatile registers ... to be restored to their factory default values". I doubt this works once you disable the debug interface. Also it would only be useful if we already had a firmware dump.

edit: The reset sequence may still work after you lock out debug because my MCU is a "Dust Devil" series chip: https://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/64718 https://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/48383

edit2: on the plus side, the CPU still works so I didn't fry anything :P

[arhi]

you are right, there are "fan5" and "fan6" connectors on the up plus 2 board :) need to trace them to see on what pins they are :D I do need another controllable fan on my up :) .. I'll update up3d forum when I trace the connections

as for debugging the existing mcu, dunno if there's an open source firmware that easily portable to LM3S5737 and doing some heavy porting to LM3S5737 makes too little sense as the porting will cost more then a replacement cpu that will run smoothieware directly (what I do now for e.g.). With this nice transcoding tool these nice folks are making I don't really see a point in tweaking current cpu, it works acceptably well with transcoding tools :D

[edbordin]

Yeah, agreed... I just thought a softmod seemed like a fun project even if from a practical standpoint it's not really worth the effort. It was more a chance to hone my skills a bit, but it looks like this board is not an easy target.

I'm going to go out on a limb here and guess that @MaikStohn is trying to use https://github.com/scanlime/facewhisperer to dump the firmware over USB using some cool power glitching techniques. Requires a fair bit of dedicated hardware and also seems like it's not guaranteed to work for all devices.

[arhi]

both fan5 and fan6 are connected directly to 12V not controllable :(

what might be useful, doorcheck connector pin1 (square) is 100R to pin4 (connector1) with some capacitance towards vss and it looks like (measured) there's 10k pullup and 10k pulldown (5V, Vss) pin2 Vss pin3 NC

so in theory door pin could be used to drive some fet that will run additional fan (P1[22] pin on NXP cpu upgrade)

[edbordin]

Yep, fan5 is directly connected to 12V on mine too. Oh well.

This older board doesn't even have the door connector. I think if I want auto levelling it will be easiest if I just take sensor readings with other hardware and use the tools here to send usb commands to move the extruder around (and optionally store the calibration data into the printer).

[arhi]

why don't you just use Z limit switch connector for autolevel?

[edbordin]

Hmm, guess that could work depending on what the stock firmware does when it unexpectedly hits the z limit. Or maybe you mean if I'm running a smoothieware board - that is probably a more sensible option :P

[arhi]

no clue how stock firmware will behave but even if you have a spare pin how will you do it with stock firmware? not sure if this transcoder can "test pin status" :( ..

with some other cpu board it should be possible :) .. lot of things I'd personally do differently then what maker of this nxp cpu board did but can't complain too much - it works :D ..

now since the cpu board looks identical between old and new motherboard, maybe you can try to bring z-probe pin directly to the cpu board?! you have the douptz schematic in this thread, one of my previous comments so you see that 3 pins go to CPU board from this segment of the board TMS, TCK and INP and they are on the CPU board

TMS -> P2, pin10 TCK -> P2, pin9 INP -> P2, pin30

it should be easy to add this and test :D, the only question is if firmware on that cpu knows how to use it now when hw is available

[edbordin]

I was thinking if I temporarily unplugged the z limit switch and plugged in a bed probe instead. Maybe I could tell it to keep driving the extruder downwards and hope that it will kill the stepper when the bed level sensor triggers. Pretty convoluted, I know.

It's hard to see from the photos I posted earlier, but this board doesn't have the douptz through-holes at all. It's interesting to note that they have used the TMS/TCK pins for that functionality, as those are the exact pins I was trying to use for SWD. The datasheet notes that another way you can effectively disable JTAG is by switching the function of those pins immediately at boot. It would be cool if they put in a backdoor USB command to re-enable JTAG by switching the pin modes back. Even if they did, without a firmware dump there's no real way to figure out how to trigger it...

Now that I think of it, the ROM files supposedly contain IO port config. I wonder if hacking one of those files would stop the firmware from switching the mode on the jtag pins...

edit: Looks like the format is very simple: https://gist.github.com/edbordin/eb0b76201760cccafe28bca34ae5a700 With enough effort you could in theory trace the mcu pin through to where it is connected. Not sure how interesting that is though.

What IS interesting is that the firmware presumably takes the base address, adds some offsets to it and then sets/clears bits at those addresses using the mask we provide. If there is no validation on the base address then we can potentially use this to write to arbitrary memory locations. So in theory if they have disabled JTAG using the soft method, if we provide the right base address + mask it may be possible to switch the mode of the JTAG pins back. I'll ponder if I'm game to try it on my CPU... There's a reasonable chance of bricking it.