Open On-Chip Debugger 0.10.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 2000 kHz none separate RCLK - adaptive Info : RCLK (adaptive clock speed) Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!
source shikra.cfg transport select jtag jtag_rclk 8
Now I found a hint, that the used JTAG protocol is called IceMaker (a next generation after a "classic" one, but before ICEpick) and it appears it doesn't use DR at all. Thus I'd need to see the data scanned out on IR.
Have you considered that you may have erased the TWC firmware (whole or partially) and it's expecting a new firmware to be loaded. Devices with upgradable firmware often have an erase command after which when rebooted you can only check the device hardware versions and write a new firmware (often protected by a checksum, sometimes cryptographically signed).Since TWC 2's behavior is very similar to TWC 1, I don't think it's a hardware problem. My best guess is it's a factory or debug mode. Or just an unstable, bugged state caused by erasing something important in NVRAM.
If all you need is many slaves, even if there is some limit enforced by slaves detecting each other, the simple solution seems to be multiple RS485 buses. The 3 slave limit may come from maximum allowed bus loading by the way, if you put more you are running at your own risk (since each slave independently terminates, too many slaves may just make the bus unreliable).Each TWC has a two BYTE id ranging from 1 to 0xFFFF. Although the manual says only 4 TWCs can be linked together, there's nothing about the protocol that implies such a limit. I've never tried simulating 4 or more TWCs on a network so I'm not sure what would happen. I suspect normally the master TWC would show an error light when it detects more than 3 other unique ids, but if TWCManager is playing master, maybe there would be no limit? Slaves could also detect the presence of more than 3 other TWCs and show an error but I'm not sure if they do or not.
I don't have specific information but you'd be surprised how much stuff like that in the industry ships unlocked.People keep suggesting JTAG, but according to this, posted in 2013:
Given all that, it seems really unlikely that Delta (maker of the boards in the TWC) left the chip containing the firmware unlocked. Unless, since TWC is designed to have upgradable firmware, maybe it's more likely to be unlocked?
If you're going to access the microcontroller via JTAG, I would strongly suggest to use TI's development software. If it is unlocked, then you could read the image out, and if I was right above that you simply erased the other other TWC's firmware, you could fix it by writing the image you read to the broken TWC microcontroller via JTAG. TI software is probably free, you'd just need to get a supported JTAG interface (or a dev kit for that microcontroller that has one built in).From the spec sheet for the TMS320F28034 chip, it includes:
Even if, by some miracle, the chip is unlocked, accessing it without breaking something requires very careful use of JTAG commands and complete understanding of what you're doing:
Given all that, I consider JTAG to be a tool of last resort. One mistake and things may be unfixable. I wouldn't want to try to use OpenOCD on a Raspberry Pi because the pi is not designed to send signals at a reliable rate.
Unfortunately I can only guess that is has something to do with temperature management. My Dec 2015 Gen1 HPWC has been working great up to full 80A on Model S as late as 2017, but throws an intermittent, undocumented (8 flashes) error when connected to a post March 2018 car (verified with 2 different new cars). The frequency of this intermittent error strongly correlates to car temperature (so outside temp, whether it has been driven recently, and how long it has been charging) - the hotter the car, the more it throws this error. The 2018 car works great with recent HPWC and even a 2017 Gen1 UMC.
Hi guys, I think I found kind of a "checksum", there is a sum of all bytes at the end (bits>7 cut off) e.g.:
c0 fb e2 03 5d 5f 00 00 00 00 00 00 00 00 a1 c0 fe
c0 fc e1 03 5d 39 00 00 00 00 00 00 00 00 7a c0 fe
These are two reset messages from my EU 3-phase wall connector (also saw that the reset messages end with c0 fe instad only c0).
Also found out that every four hours there are idle message repeated three times from the master, e.g.:
c0 fc 1d 00 00 00 00 00 00 00 00 00 00 00 1d c0
("checksum" is 1d because all zeros in between)
Have you considered that you may have erased the TWC firmware (whole or partially) and it's expecting a new firmware to be loaded.
If you're going to access the microcontroller via JTAG, I would strongly suggest to use TI's development software.
why not create a pilot signal spoofer?
are some of the bytes in there telling how much the car is drawing?
It is possible that you overwrite some configuration parameters (like a model #) but still possible the firmware got messed up:I can't have erased the whole firmware because it still behaves mostly like a TWC set to master mode. I can have TWCManager play fake slave and the broken TWC responds normally, other than it always reports state 02 (error state). I've mentioned I think I erased the TWC model information and perhaps other data, but any method I could think of that might restore them has failed.
I meant get a kit from TI that allows you to read and write the TMS320F28034 chip, like TMDSDOCK28035 F28035 Piccolo Experimenter's Kit | TI.comI ordered a CCS-compatible piece of hardware after my last post on the subject. It's shipping from China so not sure how much longer it will take to get here.
I meant get a kit from TI that allows you to read and write the TMS320F28034 chip, like TMDSDOCK28035 F28035 Piccolo Experimenter's Kit | TI.com
Btw, is the TMS320F28034 the one talking on the serial bus, or is there another microcontroller in there?
sudo apt-get update sudo apt-get install python3-pip sudo python3 -m pip install pyserial sudo python3 -m pip install sysv_ipc