GS450h RPM feedback always 0

[Bigpie]

So after a long day with Crasbe and Tom Debree etc turns out the solution was simple. The ground connection to zombie wasn't good enough. A thick ground connection direct.to chassis and the problem is gone.
I'll update the wiki to make this clear

[nkiernan]

Good to hear it was a straightforward fix

[uhi22]

Great, congratulations. Remaining question is how could the corrupted data pass the checksum test, strange. Ok, one case is an "everything zero" corruption, the sum of zeros is zero, checksum ok. But I understood that a none-zero voltage was detected, hm.

[Bigpie]

Cancel that, still having the issue.

[uhi22]

Ooops
Just have read the details above. You already have the state4Counter in the path where the checksum is ok. Does it increment now (would mean the checksum is fine) or is it stuck (would mean the checksum is wrong or no data from DMA)?
You could also add an additional debug counter in the path where the checksum is wrong, something like

image.png (8.59 KiB) Viewed 3992 times

[Bigpie]

Stuck. I did run last night for a short drive, but once it stops I have to reboot the zombie for it to start again. Just turning the inverter off isn't enough

[nkiernan]

When you mention reboot or change when it stops, do you use the park position of the gearbox and the associated HSDN signal back to the inverter? Likely not related, but I had inverter restart issues when bench testing withyout the HSDN before. Just checking if maybe a link.

[Bigpie]

Tom DeBree has been helping with this and to sum up here what we've got so far:
Changed the code to add a counter for checksum errors and added the transferSize to a spot param (note this is data left to transfer)

Code: Select all

    case 3:

        transferSize = dma_get_number_of_data(DMA1, DMA_CHANNEL6);
        Param::SetInt(Param::dmaTransferSize, transferSize);

        if(VerifyMTHChecksum(100)==0) {
            Param::SetInt(Param::checksum4Counter, counter);
            if(counter>200)
            {
                counter = 0;
            }
            else
            {
                counter++;
            }
        }

So the end of this plot, we can see that the speed is working then suddenly the DMA transfer gets stuck and the checksum errors start adding up.

So Tom discovered the DMA read it set to low priority so we went full send and set it very high
I forgot to screenshot the plot for that, but the transfer size remained at 0 (this is good, all bytes transferred) and the checksum error count incremented a couple of times
We dropped to a Medium priority to match the write and the errors returned

Ive set it to High for now to see how it goes.


NOTE:
We both do not yet fully understand the impact of the priority of the DMA (direct memory acess) on the rest of the zombie functioning. Possibly due to all the features that have been rolled in, too little time is left to write the memory

The Priority of the DMA write is MEDUIM.

[Bigpie]

So, this issue remains, even on very high priority.

Code: Select all

    case 3:

        transferSize = dma_get_number_of_data(DMA1, DMA_CHANNEL6);
        Param::SetInt(Param::dmaTransferSize, transferSize);

        Param::SetInt(Param::dmaReceiveFlags, (DMA_ISR(DMA1) & DMA_FLAGS << DMA_FLAG_OFFSET(DMA_CHANNEL6)) >> DMA_FLAG_OFFSET(DMA_CHANNEL6) );
        Param::SetInt(Param::usart2Flags, USART_SR(USART2));

I've done some logging (attached), when it's not working these 2 flags are set USART_SR_RXNE, USART_SR_IDLE, not currently sure why.

Code: Select all

/** RXNE: Read data register not empty */
#define USART_SR_RXNE			(1 << 5)

/** IDLE: Idle line detected */
#define USART_SR_IDLE			(1 << 4)