Teensy 4: Default FlexIO clock configuration is invalid about smartmatrix HOT 6 OPEN

There are many things undocumented about FlexIO, unfortunately. For example if you read the FLEXIO2_PARAM register after enabling FlexIO2, the value stored there indicates that there are 8 timers and 8 shifters on the chip rather than 4 as stated in the manual. As far as I'm aware, the extra four shifters function normally in most respects, except I think they cannot be used with DMA. It was a bit of a happy accident to discover that we could use this for SmartMatrix addressing.

from smartmatrix.

@easone do you have any thoughts on this?

from smartmatrix.

The FlexIO peripheral seems to run happily with a 480 MHz clock as far as I can tell. From my testing, increasing the FlexIO clock increases the speed at which the shifters trigger when data is copied into their buffers, which reduces delays and improves display speed slightly. I guess the manual lists a conservative maximum speed for FlexIO and it can actually be overclocked.

I will say that the 480 MHz clock doesn't seem to work perfectly with the CPU speed below 600 MHz. Some other folks have had issues as documented here: https://forum.pjrc.com/threads/67815-FlexIO-quot-Extra-quot-clock-cycle-on-8080-parallel-setup

I don't know whether a lower FlexIO clock speed would enable running the CPU slower but it seems possible... If for some reason you wanted to reduce the FlexIO clock speed, you would need to adjust the timing constants in the MatrixHardware header accordingly.

from smartmatrix.

Just confirmed that reducing the FlexIO clock speed from 480 to 240 MHz works as expected and allows the CPU speed to be reduced as low as 396 MHz. Apart from some low power application, I don't see why this provides any benefit...

For posterity: to use the 240 MHz clock speed, make the following changes:

• Clock setting in MatrixTeensy4Hub75Refresh_Impl.h should be changed to:pFlex->setClockSettings(3, 1, 0)
• Shift clock divider in MatrixHardware_Teensy4_ShieldV5.h should be changed to: #define FLEXIO_CLOCK_DIVIDER 12
• Timing constant in MatrixHardware_Teensy4_ShieldV5.h should be changed to: #define PANEL_32_PIXELDATA_TRANSFER_MAXIMUM_NS ((32*FLEXIO_CLOCK_DIVIDER*1000/240) + 200)

from smartmatrix.

I think by you comparing the behavior of FlexIO timers relative to how they behave when configured with a valid clock (per RM) is a legitimate test, verifying it is indeed using the 480 MHz its configured with. You verified this with FLEXIO2 only? Curious then where the 120 MHz comes from — perhaps one of the FlexIO functional modes, or maybe one of the possible input trigger sources, or its outputs, are the bottleneck?

I discovered the 120 MHz limitation by using NXP's MCUXpresso SDK (Eclipse IDE) while trying to configure a project equivalent to the settings used in this repo. Their "Clocks" configuration tool refuses to accept — in every way I know to try — the FlexIO PRED/PODF prescalars equal 1; or, if you hardcode any value greater than 120 MHz as a FlexIO clock root, it will flag it as an error and refuse to generate code for you. Pretty helpful tool, huh? 👎🏻

I am intending to mimic much of this project in terms of its DMA-driven FlexIO config, so I too will try using a 480 MHz clock and hope for the best.

Anyway, thanks for verifying this on a real device @easone. Sounds like this issue can probably be closed.

from smartmatrix.

Also, considering this project is using a completely undocumented extra FlexIO shifter, it really shouldn't be surprising that the FlexIO clock roots are capable of a greater-than-documented frequency...

from smartmatrix.