Merely an observation for a future FC7 tweak...
Working with PIC32MZ devices and hardware UART, TxD and RxD mappings are correct for the channels selected, but we observed that FC7 permits arbitrary selection of flow control pins which aren't appropriate when using hardware channels.
A review of the datasheet reveals designated flow control pins for each channel so not an insurmountable problem before a fix, though thought I'd mention this as it can cause a bit of head-scratching for a while - just don't ask me why I say this
All the best,
Brendan
32mZ UART Flow Control Pin Selection
Moderator: Benj
-
- Valued Contributor
- Posts: 2045
- Joined: Wed Aug 27, 2008 10:31 pm
- Location: Netherlands
- Has thanked: 553 times
- Been thanked: 1081 times
- Contact:
Re: 32mZ UART Flow Control Pin Selection
“Integrity is doing the right thing, even when no one is watching.”
― C.S. Lewis
― C.S. Lewis
-
- Posts: 243
- Joined: Tue Nov 27, 2012 12:53 pm
- Location: Cambridge, UK
- Has thanked: 140 times
- Been thanked: 118 times
- Contact:
Re: 32mZ UART Flow Control Pin Selection
Hi Jac.
Thanks for the link, which suggests that as most chips don't support hardware flow control then the software implementation will work regardless.
Regrettably however, this was not our experience with the 32MZ. After an engineer selected pins for flow control in FC7, and spending considerable time exploring why it wasn't working, the data sheet was reviewed and flow control pins were electrically reassigned to specified pins supported by hardware channels of the PIC. Only then did UART start working.
Best regards,
Brendan
Thanks for the link, which suggests that as most chips don't support hardware flow control then the software implementation will work regardless.
Regrettably however, this was not our experience with the 32MZ. After an engineer selected pins for flow control in FC7, and spending considerable time exploring why it wasn't working, the data sheet was reviewed and flow control pins were electrically reassigned to specified pins supported by hardware channels of the PIC. Only then did UART start working.
Best regards,
Brendan
LinkedIn Profile...
http://www.linkedin.com/in/brendantownsend
http://www.linkedin.com/in/brendantownsend
- Benj
- Matrix Staff
- Posts: 15312
- Joined: Mon Oct 16, 2006 10:48 am
- Location: Matrix TS Ltd
- Has thanked: 4803 times
- Been thanked: 4314 times
- Contact:
Re: 32mZ UART Flow Control Pin Selection
Hi Brendan,
That's interesting I wonder if the hardware flow control pins are being enabled somehow. Which specific chip are you using and I will investigate to make sure these are switched off.
Also are you using the chip with a bootloader? Just in case it is maybe the bootloader that is switching on the hardware flow control.
That's interesting I wonder if the hardware flow control pins are being enabled somehow. Which specific chip are you using and I will investigate to make sure these are switched off.
Also are you using the chip with a bootloader? Just in case it is maybe the bootloader that is switching on the hardware flow control.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
-
- Posts: 243
- Joined: Tue Nov 27, 2012 12:53 pm
- Location: Cambridge, UK
- Has thanked: 140 times
- Been thanked: 118 times
- Contact:
Re: 32mZ UART Flow Control Pin Selection
Hi Ben.
The device concerned is PIC32MZ2048EFG144, and no bootloader.
It's a bit of a handful, and we're progressively getting to know it better, though appears to set itself apart in the way you have to configure and use it. Other things seem not to make sense, such as growing silicon errata (the 'fix' for primary and secondary oscillators, not working as crystal clocks, being not to use them was amusing), and configured/enabled ADC's still returning noise (still investigating that). One of the ICSP pins was also mapped as UART RxD but refused to work as such, so we moved it and all was well.
To resolve the flow control issue it was a matter of using the specified pins for the chosen UART block, and affirming flow control pin selections in FC7. I don't believe we attempted to preset registers to disable hardware flow control as we'd expected the choice to be arbitrarily selectable (as per your separate post), until we discovered this behaviour.
Of-course I'm unable to rule out pin-specific weirdness and bad luck in choice (similar to the RxD issue above), though I'd generally recommend anyone using flow control on the PIC32MZ to stick with pins designated by datasheet when using hardware blocks if they can to minimise potential for issues.
Probably just the hallmarks of early silicon, unless you should highlight an oversight Ben
Best regards,
Brendan
The device concerned is PIC32MZ2048EFG144, and no bootloader.
It's a bit of a handful, and we're progressively getting to know it better, though appears to set itself apart in the way you have to configure and use it. Other things seem not to make sense, such as growing silicon errata (the 'fix' for primary and secondary oscillators, not working as crystal clocks, being not to use them was amusing), and configured/enabled ADC's still returning noise (still investigating that). One of the ICSP pins was also mapped as UART RxD but refused to work as such, so we moved it and all was well.
To resolve the flow control issue it was a matter of using the specified pins for the chosen UART block, and affirming flow control pin selections in FC7. I don't believe we attempted to preset registers to disable hardware flow control as we'd expected the choice to be arbitrarily selectable (as per your separate post), until we discovered this behaviour.
Of-course I'm unable to rule out pin-specific weirdness and bad luck in choice (similar to the RxD issue above), though I'd generally recommend anyone using flow control on the PIC32MZ to stick with pins designated by datasheet when using hardware blocks if they can to minimise potential for issues.
Probably just the hallmarks of early silicon, unless you should highlight an oversight Ben
Best regards,
Brendan
LinkedIn Profile...
http://www.linkedin.com/in/brendantownsend
http://www.linkedin.com/in/brendantownsend