morganThe groundwork for getting started on this project was laid out in this 2018 EEVBlog forum post.
https://www.eevblog.com/forum/manufacture/neoden-tm245p-teardown-and-upgrade/
In it, Luiz Renault suggests the data rate is 512kbit/s based on the smallest pulse width. My results before vary slightly but should be in the same range.
The minimal bit length looks to be ~1.740us, not far off Luiz's 1.960us that can be seen in the scope shot in the second post. So 512kbit/s seems like a reasonable rounding point. Luiz also indicated they were able to decode the data, but not what the content looked like. There was also no indication of byte size, start/stop bits. So more digging....
The next image is a single frame.
Yellow is STM32 #PA9 (USART1_TX) <> VP230 #D (input)
Cyan is STM32 #PA10 (USART1_RX) <> VP230 #R (output)
Connecting a UART RX pin to the STM TX pin yields some results but things are inconsistent. At 512kbit/s nothing seems to change in the stream when messages are sent, to say, activate a feeder. Instead the same 3 bytes are seen, 0x00, 0xe0, 0xf0. By contrast when I previously thought the baud rate was 460800 I could see a noticeable 'shift' when sending commands. I've tried both 1 or 2 stop bits but cannot notice any change.
When connecting RXs together to listen to 'return data' only the 0x00 and 0xf0 bytes are seen. When sending commands this time, it seems like that data... might be changing but it's inconsistent, and seemingly no matter which feeder I test the same byes is sent. 0xf8.
Not sure what to poke next here, I've been looking into using TIOCGICOUNT to check for framing errors, possibly yielding the (in)correct baud rate, but its always returning 0 so unsure if that's even working.
Looking forward to some suggestions.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
If you could post a VCD file of the captured data, I'll stare at the bits.
Also remember, unless you have followed the signal back to the UART that made it, don't count on the signal being made by a UART. My most recent project had an IR-LED attached to a SPI port. The LED's driver transistor turn-on time narrowed the pulse widths, causing me to over-estimate the baud rate.
Are you sure? yes | no
The DS1052Z dumps csv files, I've added two to the Files section of the project, and in the data directory of the git repo.
https://git.oit.cloud/morgan/RE-TM245P/src/branch/development/data
The signal is being read at the USART1_TX pin on the STM32
Are you sure? yes | no
Take a look at DeviceNet protocol, while I twiddle with converting csv to vcd. But, looking at the images posted by Luiz on eevblog, the length of the packets appear to match what is allowed in the protocol. RX data being a 0 data byte packet, while TX data is 6 or 7 bytes.
Also, when you have a chance, take a look at pin 100 (USART1_CK). Perhaps the firmware developer enabled it for us.
Are you sure? yes | no