MUT/RAM logging
Sep 19, 2021, 06:44 AM
#31
// logging/DMA commands - uses DMAC0 (SND) and DMAC1 (RCV)
0xFFFF7D14/6 are tcnt2a timestamps for delays
0xFFFF7D18/A is the decoded command and command state bit vector
// ICR DMA capture - uses DMAC2
0xFFFF7D1C dmac2 input capture DMA destination
0x0000FDB4 function to check if DMAC0/1 TCRs are at 0
0x0000ADD8 function pointers to perform some operation for command sequencing
0x000092AE call site for TCR check
0xFFFF7D14/6 are tcnt2a timestamps for delays
0xFFFF7D18/A is the decoded command and command state bit vector
// ICR DMA capture - uses DMAC2
0xFFFF7D1C dmac2 input capture DMA destination
0x0000FDB4 function to check if DMAC0/1 TCRs are at 0
0x0000ADD8 function pointers to perform some operation for command sequencing
0x000092AE call site for TCR check
Last edited by orion4096; Sep 20, 2021 at 06:40 AM.
Dec 9, 2021, 08:14 PM
#33
Dec 9, 2021, 10:09 PM
#34
Dec 9, 2021, 10:13 PM
#35
Dec 9, 2021, 10:48 PM
#37
Aug 4, 2023, 01:25 AM
#38
The CAS interrrupt gets called every 1.25ms. The main loop has a delay which only allows it to execute at most every 10ms (8x CAS interrupts). The command decoder, handler for 100 hz logging, and reads/writes are in the main loop. And it looks like there is also a minimum required 20ms delay between the end of one command and the start of the next. Normally this protected by the client waiting for the response, but since the response is removed I can see there being 20ms + (2 to 3 mainloop iterations to decodeCmd/performWrite, cleanup) * 10ms = ~50ms of necessary delay. As long as the read and write is handled in the mainloop a single command won't get much faster. It may be possible to add a EOW (End of Write) bit in the write packet so the state machine stays live but data would need to be double buffered and it gets complicated. You would still need to add pauses to slow it down to every 10-20ms. There are other solutions:
(1) Add new read/write commands that setup DMAC so raw data can be transferred to/from an address after the initial command is sent. The write will generate a response and only after receiving the response the client can start sending data.
This should get close to the full 62500 data rate for large data (minus serial overheads). Small reads/writes will still be slow since 1 command can only be done every ~90-100 ms. But when sending lots of data in one command it will be at a high rate.
(2) Custom decoder in the serial data ready interrupt which sets up DMAC for these new read/write commands.
This should have low latency and high data rate. Not sure if it can even be made to work, though. Something has to keep the mainloop DMA state machine from triggering. The way this works for OBD/MUT transfers is the 5baud init causes it to get disabled. When the ECU boots up it sets up the receive buffer DMA for 0x33 bytes which is why commands can be sent @ 62500 baud with no setup work. Would require changes to not setup the DMA right away. This seems too complicated.
(3) DMAC complete interrupt to decode new commands and setup DMAC for data or hand off other commands to existing main loop state machine.
Right now the main loop polls on idle DMA transfer counts. The interrupt is not used. This would also have low latency and high rate like (2). This seems like the best approach since the DMAC completion interrupt can immediately manage the RCV/SND fifos and state before the serial interrupt or mainloop do their work.
I'll have to think about it more as there are problems with all 3 approaches. Not sure if or when something can be coded and tested. It's not a simple thing to change.
(1) Add new read/write commands that setup DMAC so raw data can be transferred to/from an address after the initial command is sent. The write will generate a response and only after receiving the response the client can start sending data.
This should get close to the full 62500 data rate for large data (minus serial overheads). Small reads/writes will still be slow since 1 command can only be done every ~90-100 ms. But when sending lots of data in one command it will be at a high rate.
(2) Custom decoder in the serial data ready interrupt which sets up DMAC for these new read/write commands.
This should have low latency and high data rate. Not sure if it can even be made to work, though. Something has to keep the mainloop DMA state machine from triggering. The way this works for OBD/MUT transfers is the 5baud init causes it to get disabled. When the ECU boots up it sets up the receive buffer DMA for 0x33 bytes which is why commands can be sent @ 62500 baud with no setup work. Would require changes to not setup the DMA right away. This seems too complicated.
(3) DMAC complete interrupt to decode new commands and setup DMAC for data or hand off other commands to existing main loop state machine.
Right now the main loop polls on idle DMA transfer counts. The interrupt is not used. This would also have low latency and high rate like (2). This seems like the best approach since the DMAC completion interrupt can immediately manage the RCV/SND fifos and state before the serial interrupt or mainloop do their work.
I'll have to think about it more as there are problems with all 3 approaches. Not sure if or when something can be coded and tested. It's not a simple thing to change.
Aug 4, 2023, 08:19 PM
#40
I sold my evos ten years ago, the code never ceases to be interesting. I probably put it poorly, I ask for help in reversing that function if you have time, hydra decompiles well but I am at a dead end with the calculation of function addresses, if you look and mark where I am wrong or mark stack variables it would be great.
Thread
Thread Starter
Forum
Replies
Last Post