Atmel SAM E70 USART driven by PCK4 - not working

[zphaze]

Hi,

Granted there are some good SAM programmers here...
I have an issue with my ATSAME70Q21B where I can't seem to be able to use PCK4 to drive the USART0 SCK in SPI master mode.

I'm using MPLAB X IDE 6.20 with Harmony 3/MCC. Frankly nothing really bad to say about the code generation so far... makes things a bit quicker despite the fact I re-write a lot of functions to use registers my way as to optimize and time some things manually.

The code generated seems OK...
For PCK4 configuration :

Code: [Select]

static void CLK_ProgrammableClockInitialize(void)
{
    /* Disable selected programmable clock  */
    PMC_REGS->PMC_SCDR = PMC_SCDR_PCK4_Msk;

    /* Configure selected programmable clock    */
    PMC_REGS->PMC_PCK[4]= PMC_PCK_CSS_MCK | PMC_PCK_PRES(0);

    /* Enable selected programmable clock   */
    PMC_REGS->PMC_SCER =    PMC_SCER_PCK4_Msk;

    /* Wait for clock to be ready   */
    while( (PMC_REGS->PMC_SR & (PMC_SR_PCKRDY4_Msk) ) != (PMC_SR_PCKRDY4_Msk))
    {
        /* Nothing to do */
    }
}

The code for USART0 initiatialization:

Code: [Select]

void USART0_SPI_Initialize( void )
{
    /* Configure USART0 mode to SPI Master (0x0E) */
    USART0_REGS->US_MR = US_MR_SPI_USART_MODE(US_MR_SPI_USART_MODE_SPI_MASTER_Val);

    /* Reset SPI RX, SPI TX and SPI status */
    USART0_REGS->US_CR = (US_CR_SPI_RSTRX_Msk | US_CR_SPI_RSTTX_Msk | US_CR_SPI_RSTSTA_Msk);

    /* Configure clock source, clock phase, clock polarity and CKO = 1 */
    USART0_REGS->US_MR |= (US_MR_USART_USCLKS_PCK | US_MR_SPI_CHRL(US_MR_SPI_CHRL_8_BIT_Val) | US_MR_SPI_CPHA(0x0U) | US_MR_SPI_CPOL(0x0U) | US_MR_SPI_CLKO(1U));

    /* Enable TX and RX */
    USART0_REGS->US_CR = (US_CR_SPI_RXEN_Msk | US_CR_SPI_TXEN_Msk);

    /* Configure USART0 Baud Rate */
    USART0_REGS->US_BRGR = US_BRGR_CD(10U);

    /* Initialize instance object */
    usart0SPIObj.callback = NULL;
    usart0SPIObj.context = 0U;
    usart0SPIObj.transferIsBusy = false;
}

Upon trying any kind of communication, I can't see any clock on the USART0_SCK pin with a Salae logic analyzer. Nothing, nada.
PCK4 just seems to not make it work at all, despite being the same exact frequency as MCK.
My baud rate divider for USART is set to 10, more than the required minimum of 6 from the datasheet.

When changing back to master clock and regenerating the code, everything works beautifully. The ONLY thing that changes from working to not working is PCK4 which is set at 150MHz just like the master clock MCK.

The data sheet states :

USART0 config in MCC code generator :


Would there anyone who sees a reason it wouldn't work?

EDIT: What's more, PMC.SCSR register with AND mask 1<<3 returns 0b1000 which means PCK4 is (technically?) enabled...
I'm probably missing something I guess I just don't understand what.

EDIT2: Tried with 4 different boards, all not working. Can't believe all those 4 boards would be defective/toast. For each, everytime I go back to MCK, it works.
My SOM is a NetBurner MODM7ae70-100IR fwiw, its not the Xplained board. Regardless, it should work as the datasheet seems to state PCK4 is linked to USART0 within the chip.

[ataradov]

Have you actually configured correct peripheral functions for the pins? Nevermind, read the part about working with the other clock.

I don't see anything wrong with the code shown here.

[ataradov]

Ah, wait, I think I remember running into this. I think PCK only works in UART mode (I think not even USART). I will try to find previous investigation on that tomorrow when I'm in the office. 

[zphaze]

Are you sure granted the DS states it can?
(see here)


And Microchip MCC would be wrong as well in its clock configuration menu haha
Thanks for your time, much appreciated.

[ataradov]

It can, but only in plain UART mode. It can't be used to generate synchronous clock. To clarify, I mean asynchronous mode of the USART peripheral, not UART peripheral.

So, you can't output clock generated from the PCK on the pin, it can only be used for UART baud-rate generation.

[zphaze]

Check my first post, the last thumbnail image in the original post.
In SPI master the datasheet states USCLKS can be 0, 1 or 2.
2 corresponds to using PCK according to the upper table in the same image.

I'm not saying you're wrong because something obviously isn't right from my experimentation.
But the DS would be quite mistaken here.

[ataradov]

Yeah, this part of the DS is wrong, assuming I remember correctly. I also bet there is a JIRA to fix the datasheet, but the last content change happened in 2022, so the request is probably still pending.

[SiliconWizard]

Looks odd to me, who has experience with the SAMD21 & SAMD51, but not the E70. The former have several identical SERCOM peripherals and there is no such restriction with these that I know of.
I would have assumed a similar architecture on the SAME70. Apparently not?

[ataradov]

Apparently not?

SAM E70 is completely different. It predates SERCOMs and is way more traditional device with a fixed clock tree and separate peripherals.

[ataradov]

I found the old discussion on this. Yes, this is a confirmed behavior. PCK is supported only in UART mode. Documentation changes were made in the internal version, so when the next datasheet is released, it should be fixed.

PCK there is more of a late stage addition to support UART baudrate independent from the system clock. Internally it is handled separately from the other clocks.

[zphaze]

Oh well... bit of a disappointment as I will have more interrupts but I can circumvent my issue.
I wanted to use PCK4 to steer the USART clock and use both the baud clock divider and the PCK4 divider to make a double divider and output to a DAC IC at a set (adjustable) frequency with a DMA circular buffer containing signal values.
This way the CPU would never even be called for pushing values to the DAC, granted the overall signal sampling frequency would have had a resolution of 17668 exactly (two 256 values dividers), which was acceptable.
But without PCK4 I'm down to a 256 resolution clock which is just far too small, I'll have to revert back to a timer and update the DMA transfer from there.

Since you're part ot Microchip, one thing I'd have liked to have with SAM is external trigger for DMA transfers. I know NXP RT does it, STM32 as well. You can basically pace DMA transfers without CPU intervention from using a PIN or some specific timer lines. Could be a nice feature for some upcoming versions of SAM.

Thanks for your time though, you saved me a lot of time from debugging something that wasn't even doable. I very much appreciate it.

 

Looks odd to me, who has experience with the SAMD21 & SAMD51, but not the E70. The former have several identical SERCOM peripherals and there is no such restriction with these that I know of.
I would have assumed a similar architecture on the SAME70. Apparently not?

Have you tested it? (USART, SPI MASTER mode, PCK clock)
In my case the DS was clear it could be done but its mistaken. Could it be the same for SAMD?

[ataradov]

Since you're part ot Microchip

I have as much impact on product planning as you do.

external trigger for DMA transfers.

I have not tried, but I think using timer trigger in the XDMAC_CC.PERID would let you do timed transfers. The transfer source and destination can be anything, it does not need to be the timer itself. I think that should work. I don't see a way to do that from a pin though.

Could it be the same for SAMD?

SAM D use fundamentally different clock tree and peripherals. There is no point in comparing them.

[zphaze]

have not tried, but I think using timer trigger in the XDMAC_CC.PERID would let you do timed transfers. The transfer source and destination can be anything, it does not need to be the timer itself. I think that should work. I don't see a way to do that from a pin though.

Unless you know something I don't, which is very much possible, the DS seems to state timers generate DMA events for Capture Mode in order to move RA and RB to memory.
Afaik I don't think there is a way to generate a DMA event for a timer reaching its period for example (afaik), so there would be no PERID suitable for my case I think.

[ataradov]

Yeah, it looks like it is capture only. I assumed it would be possible to have it trigger the event, but ignore the actual transfer. But this would require external pin trigger.

Anyway, this is addressed in new devices already. Devices like SAM D51 have real timer triggers, which just trigger the transfer and don't require the transfer to be to or from the timer.