PIC32MZ UART Troubles - Pulling my hair out...

[Brendan]

Hello All.

I'm wondering if seasoned experts amongst us could shed any light...

I've been pulling my hair out trying to get a single basic UART channel working on the PIC32MZ2048EFG144.

100MHz system clock settings suitably confirmed as UART Tx/Rx works perfectly fine in software mode at 115.2kbps, and my debug LED flashes at the intended 1Hz. Not a sausage however in UART hardware mode, with or without flow control. Unfortunately, Flowcode UART and timer macros don't appear to work with this PIC (I haven't got as far as invoking PWM yet).

If host comms only were required I'd be fine with software mode, but unfortunately I'm reliant on all six UART channels as five of them are supporting IrDA Tx/Rx.

I'd like to simply start by asking if anyone has actually ever got the PIC32MZ successfully working with humble UART comms and/or PCM? Armed with a few pointers, I've no doubt the rest will soon start falling into place.

Interestingly, timer interrupts don't work either. Doubtless interrupts have something to do with it, and not the only issue I'm sure.


From app notes and datasheet, here's a summary of my unsuccessful attempts to configure registers in a starting C block thus far (including frustrated experimentation)...

/ OSCILLATOR PRE/PLL/POST CONFIG
// Clock freq. 100MHz, phase-locked to 24MHz clk in...

OSCCONbits.SLP2SPD=1; // use INTRC until the chosen clock is ready
OSCCONbits.NOSC=0x01; // selects the system PLL
OSCCONbits.SOSCEN=0; // disable secondary oscillator

//Using a 24MHz external clock source, for a 100MHz system clk
SPLLCONbits.PLLIDIV=0x2; // divide by 3
SPLLCONbits.PLLMULT=0x31; // multiply by 50
SPLLCONbits.PLLODIV=0x2; // divide by 4

// Enable all timers
T1CONbits.ON=1;
T2CONbits.ON=1;
T3CONbits.ON=1;
T4CONbits.ON=1;
T5CONbits.ON=1;
T6CONbits.ON=1;
T7CONbits.ON=1;
T8CONbits.ON=1;
T9CONbits.ON=1;

U1MODEbits.ON=1;
U2MODEbits.ON=1;
U3MODEbits.ON=1;
U4MODEbits.ON=1;
U5MODEbits.ON=1;
U6MODEbits.ON=1;

// Enable all UART interrupts
IEC3bits.U1TXIE=0x1;
IEC3bits.U1RXIE=0x1;

IEC4bits.U2TXIE=0x1;
IEC4bits.U2RXIE=0x1;

IEC4bits.U3TXIE=0x1;
IEC4bits.U3RXIE=0x1;

IEC5bits.U4TXIE=0x1;
IEC5bits.U4RXIE=0x1;

IEC5bits.U5TXIE=0x1;
IEC5bits.U5RXIE=0x1;

IEC5bits.U6TXIE=0x1;
IEC5bits.U6RXIE=0x1;

//PB1DIV does not have enable/disable control
PB1DIVbits.PBDIV=0; (100MHz)

PB2DIVbits.ON=1;
PB2DIVbits.PBDIV=0; // divide by 1 (100MHz)

PB3DIVbits.ON=1;
PB3DIVbits.PBDIV=0; // divide by 1 (100MHz)

PB4DIVbits.ON=1;
PB4DIVbits.PBDIV=0; // divide by 1 (100MHz)

PB5DIVbits.ON=1;
PB5DIVbits.PBDIV=0; // divide by 1 (100MHz)

//PB6DIVbits.ON=1; // Errors when building
//PB6DIVbits.PBDIV=0; // divide by 1 // Errors when building

//PB7 drives the core so excluded from the above

/*
For standard UART speed (x16 clk), UxBRG = 53.25 for 115200 kbps, calculated thus...
UxBRG = [ (PeripheralBusClock / (16 x BaudRate) ] -1
*/

U1BRG=53;
U1STA=0;
U1MODE=0x8000;
U1STASET=0x1400;
// U1MODEbits.UEN=0b10; // enables RTS-CTS flow control
// U1MODEbits.IREN=1 // enables IrDA mode

U2BRG=53;
U2STA=0;
U2MODE=0x8000;
U2STASET=0x1400;
// U2MODEbits.UEN=0b10; // enables RTS-CTS flow control
// U2MODEbits.IREN=1 // enables IrDA mode

U3BRG=53;
U3STA=0;
U3MODE=0x8000;
U3STASET=0x1400;
// U3MODEbits.UEN=0b10; // enables RTS-CTS flow control
// U3MODEbits.IREN=1 // enables IrDA mode

U4BRG=53;
U4STA=0;
U4MODE=0x8000;
U4STASET=0x1400;
// U4MODEbits.UEN=0b10; // enables RTS-CTS flow control
// U4MODEbits.IREN=1 // enables IrDA mode

U5BRG=53;
U5STA=0;
U5MODE=0x8000;
U5STASET=0x1400;
U5MODEbits.UEN=0b10; // enables RTS-CTS flow control
// U5MODEbits.IREN=1 // enables IrDA mode

U6BRG=53;
U6STA=0;
U6MODE=0x8000;
U6STASET=0x1400;
// U6MODEbits.UEN=0b10; // enables RTS-CTS flow control
// U6MODEbits.IREN=1 // enables IrDA mode


Many thanks in advance,

Brendan

[stefan.erni]

Hi Brendan

I have similar problems with the PIC.(PIC32MZ2048EFG100)
For example, if I set a Uart hardware to 115.200Bd I have in the terminal program to select 128,000Bd. If I choose 256,000 Bd then I can select the terminal program to 256000Bd. Good is the Uart can transmit up to 1,500,000 Bd. A practical module was the modul of digilent

https://store.digilentinc.com/pmod-usbu ... interface/

But I do not know yet how I should make the connection to the ESP8266 (WLAN Modul) and RN42 (Bluetooth-Modul) correctly. They do not always work reliably. The both module need 115.200Bd. But I'm not sure if it's a Bd rate problem.

Interestingly, timer interrupts don't work either. Doubtless interrupts have something to do with it, and not the only issue I'm sure.

For the Interrupt, check if you have choose the right mips.....

viewtopic.php?f=7&t=19508&hilit=interrupt


regards
Stefan

[Brendan]

Hi Stefan.

Many thanks for the pointer regarding MIPS32, which wasn't set as prescribed. That's one positive step forward for sure

Unfortunately, the PIC32MZ has all the hallmarks of poor silicon rushed to market, particularly as...

The primary and secondary crystal oscillators don't work in Ver A silicon
Serious issues dynamically changing PWM (prescribed sequences notwithstanding)
An I2C channel was reportedly robbed (disabled) to fix an issue elsewhere with the chip on later silicon

...but there are other serious issues and workarounds that feature in the errata.

Other guys I know are using MPLAB-X and Harmony (UARTs working with that), though I've no doubt that many silicon workarounds and fixes are buried in Microchip's protected libraries. It is particular problems with PWM that I'm trying to address with the flexibility of Flowcode, and would be rather a coup if I can pull it off, but if I can't even get the humble UART working then I fear I'm on a road to nowhere.

Should magic happen with your help and links I'll certainly let you know - and thanks again !

Brendan

[Brendan]

Thanks Stefan regarding the BOOTISA register. Once set I was seeing comms, but garbled random characters.

After disabling all the C blocks I'd created in my frustrations to manually set registers, and after further experimentation, I discovered that the actual comms Baud rate was precisely half of the speed defined in the Flowcode component. As the debug LED flash indicates correct system clock timing, it's doubtless an issue with PBCLK2 (that the UART uses by default).

As CCP references PBCLK3 (for required PWM), I can either fudge Flowcode settings for PWM and UART, or play around with the two clock prescalers independently. Currently I'm declaring a custom baud rate of 230400 in the Flowcode UART component for a super-reliable 115200.

Another incidental observation was attempting to set IO bits to flash LEDs, with 'single bit' settings used in the respective output components. However, only one of the three affected port pins (each being on different ports and relative bits) would dynamically change the pin - until I used the 'masked' option instead, at which point all behaved as expected. One for Ben I think.

I'll post back with any further discoveries, but for the meantime I'm back on track, so many thanks again Stefan for chipping in.

All the best,
Brendan