Porting to the Retevis RT50 (aka TYT MD-680D)

Discussions related to the firmware code development
VK3KYY
Posts: 7481
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by VK3KYY » Wed Feb 15, 2023 8:34 pm

Re:C6000 SPI

I have seen some other radios where the SPI to the C6000 had to be bit-banged. Just copy the Flash SPI code

EA5JAQ
Posts: 86
Joined: Thu Jul 16, 2020 6:08 am

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by EA5JAQ » Fri Feb 17, 2023 12:41 am

VK3KYY wrote:
Wed Feb 15, 2023 8:34 pm
I have seen some other radios where the SPI to the C6000 had to be bit-banged. Just copy the Flash SPI code
Yes. I've noticed that the RT3S/MD-UV380 doesn't use MCU's native SPI like the GD77, etc. and instead they connected the C6000 to random GPIO pins in the MCU. Looks like this radio works in a similar way.

I've been trying to get my DM-1801 to communicate with the C6000 via bit-banged SPI instead of SPI0, just to test it in a platform I know so when I port it to the RT50 I can be sure it'll work. I've set the pins as GPIO (instead of SPI0) and used as a model the functions "spi_flash_enable", "spi_flash_disable" and "spi_flash_transfer" in hardware/SPI_flash.c to make a similar system for the C6000 SPI in interfaces/spi.c. But so far I haven't had much luck and couldn't make it work.

It compiles with no errors, but then the radio does not play any sounds and also does not transmit or receive DMR, due to SPI not working properly I assume. Weird thing: it transmits and receives perfectly in VHF FM, but in UHF only receives (and really badly) in VFO mode :? doesn't make much sense. Maybe I need to add some delays so the baudrate is lower. I've seen in spi_flash_transfer some "__asm volatile( "nop" );" commented lines, I tried them but didn't change anything. I've seen that in the OpenRTX source they use 1 microsecond delays.

Most probably it's a silly mistake I haven't found yet, I'll keep trying tomorrow. If it works like that in the RT3S, I'm sure it could work here too.

VK3KYY
Posts: 7481
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by VK3KYY » Fri Feb 17, 2023 3:44 am

Check the clock edge / polarity for the SPI to the C6000, it may not be the same as the Flash chip.

But there are loads of other reasons why DMR may not be working, as its the very last thing we ever get working in the firmware.

I'll email you some code but its not for the MK22 so would need modification to run on your hardware

EA5JAQ
Posts: 86
Joined: Thu Jul 16, 2020 6:08 am

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by EA5JAQ » Fri Feb 17, 2023 9:18 am

VK3KYY wrote:
Fri Feb 17, 2023 3:44 am
Check the clock edge / polarity for the SPI to the C6000, it may not be the same as the Flash chip.

I'll email you some code but its not for the MK22 so would need modification to run on your hardware
I had already tried both clock edge configurations. :cry: I’m sure it’s gonna be some little mistake I didn’t notice yesterday.

Thank you so much for the code, I’ll adapt it and see what happens.
VK3KYY wrote:
Fri Feb 17, 2023 3:44 am
But there are loads of other reasons why DMR may not be working, as its the very last thing we ever get working in the firmware.
I know, that’s why instead of trying it in the RT50 (where I’ll have a thousand more bugs), I’m trying it in the DM-1801 using the stable release and only modifying the C6000 SPI part. That way when I use it in the RT50 i can be sure (to a certain level) that if DMR doesn’t work it can be another problem but not SPI.

EA5JAQ
Posts: 86
Joined: Thu Jul 16, 2020 6:08 am

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by EA5JAQ » Sat Feb 18, 2023 12:34 pm

After hours and hours I found one of the problems... my code was right but I had MOSI and MISO mixed up :lol: I got confused because, for the flash's SPI, in gpio.h MOSI is labeled DO, and MISO is labeled DI; whereas for SPI0 and SPI1 is the other way round. So I was sending the data to the C6000's output instead of the input! I feel a bit stupid, I checked everything and the main problem was the most obvious one. It took me just a quick look at the C6000 datasheet to realise.

There is also another issue with the timing. I've tried with different delays and so far the best one I've found is adding "for(volatile int x=0;x<6;x++);" in the same places that you did, but it works inconsistently. For example, when I turn on the radio sometimes plays the boot melody at the normal rate but kind of garbled and in a lower tone, and sometimes the boot melody beeps sound fine but the melody is played slowly. Normal menu beeps sound like "brrr". So I just need to get the delays and the timing right (I'll try different values in the for loops) and it'll work fine. I don't know if the compiler optimisations might be causing issues too.

I might try later to use actual delays (using vTaskDelay maybe, but I think those will be too long) instead of "for" loops, but at the moment I'll be happy enough if I make it work.

After I have working SPI communication to the C6000, I just need to wait a couple weeks for the Flash and EEPROM chips to arrive from China, solder them, flash the firmware, load the Flash and EEPROM backups and start finding bugs. The rest of the pinout is already mapped, and it's pretty similar to the rest of the platforms (but weirdly enough: rx and tx audio multiplexers seem to work the opposite way).

VK3KYY
Posts: 7481
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by VK3KYY » Sat Feb 18, 2023 8:21 pm

The RTOS delays will be too long for the SPI. You could try increasing the value used by the for() loop
Also you may need to add some other delays in using for() loops to slow down the data rate.

If you have a logic analyser you could compare the hardware and the bit-banged waveforms

BTW , if you do not have one of those 8 channel $10 USB logic analyser donges,you should buy one

E g.

https://www.ebay.es/itm/USB-Logic-Analy ... 3699738437

EA5JAQ
Posts: 86
Joined: Thu Jul 16, 2020 6:08 am

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by EA5JAQ » Sat Feb 18, 2023 9:50 pm

I've been trying this afternoon with different values in the for() loop. If I use the code you sent me, I need 3 iterations in the first for() delay, six in the second and three in the third. Changing the values in the for() loops seems to be really sensitive, as only with those values I get any communication at all. With any other values I've had no luck. I also tried adding "nop" instructions in assembly inside the delay loops and that seems to lower the iterations needed.

But it doesn't work consistently. It sometimes works playing the tones slowly, sometimes plays them kind of buzzing, sometimes they sound garbled and in a lower tone and sometimes they don't work at all. All with the same binary :? But at least it's doing something, it's a start.
VK3KYY wrote:
Sat Feb 18, 2023 8:21 pm
If you have a logic analyser you could compare the hardware and the bit-banged waveforms
Really really good idea, I was running out of things to try, as I've been changing lines around blindly for hours, without knowing where exactly is the problem. I just bought one and I'll see what I find out.

Thank you :)

VK3KYY
Posts: 7481
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by VK3KYY » Sat Feb 18, 2023 10:02 pm

Use USB logic analyesers are really good.

They are a clone of an old Saelogic analyser, so you download and use the old Saelogic windows application, or you can use SigRok

The cheap analyser is good enough for doing most debugging, however don't try to use too many pins as the sample rate goes down

The sample rate only works at full speed if you only use 1 pin. When you use 2 pins the sample rate is 50%, 4 pins its 25% of max sample rate

I ended up buying a much more expensive 100Mhz 16 channel version, e.g. (https://www.aliexpress.com/item/4000386048107.html) but 99% of the time I don't need the extra speed and they are 10 x the price of the 24Mhz versions

EA5JAQ
Posts: 86
Joined: Thu Jul 16, 2020 6:08 am

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by EA5JAQ » Sat Feb 18, 2023 10:31 pm

Yeah for little projects like this the cheap one will probably be enough. In this case I'm really lucky because this is the easy part, I've just had to map the pins and get SPI0 bit-banging working. I'm realising now the amount of work it took to make the C6000 work due to the lack of documentation (I suppose you had to use the analyser to get the start sequences, etc. and find out what they did). That's really impressive.

After solving this SPI problem and when I receive the memories, it'll be just a matter of getting the rotary to work and also the 7 segment display, which I've already analised and figured out how it works (it's just a regular multiplexed 7-segment display with extra lights for DMR, CT, SCAN, etc).

It's sad that this won't benefit many people, as this radio's encryption hasn't been cracked as far as I know. And also it's very limited if you don't add Flash and EEPROM chips. But if at some point it was cracked, it would be fairly easy to create a test version to dump the MCU ROM and see how the original firmware stores the codeplug, calibration, etc in the internal ROM. That could make this radio fully supported for everyone, but I don't see it happening as it has been discontinued as far as I know and also there's the MK22 shortage problem.

VK3KYY
Posts: 7481
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Porting to the Retevis RT50 (aka TYT MD-680D)

Post by VK3KYY » Sun Feb 19, 2023 2:41 am

It was very hard to get DMR working on these radios in the first place

most of that work was done by Kai DG4KLU, but he only managed to get Tier 1 working, which does not have Timeslots

Because we have very limited documenation, most of the functionality for the DMR code, is done by making recordings of what data was being set to the C6000 by the official firmware, and then mimic what the official firmware does

Later in the development, Colin G4EML was able to understand some more information from the partial data sheet which we have, so that we had a bit more understanding of what the data actually means, but there is still a lot of data which we don't understand.

The same partially applies to the AT1846S. There is only partial documentation for this chip, and some important registers and settings are not documented and I had to find some important information by trial and error

With the UV380 we also found the C6000 needed different setup data to the GD77, but we don't know why

Post Reply