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 ***@***.***> 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 <#45 (comment)>, 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)