Teensy 4.0 First Beta Test

Status
Not open for further replies.
Again I am maybe not the best one to answer here.
But one thing I noticed was:
Code:
    CORE_PIN1_CONFIG = 0x12;
Will set pin 1 to = 010 ALT2 — Select mux mode: ALT2 mux port: LPUART6_TXD of instance: lpuart6

Should probably be: 0x10 for 000 ALT0 — Select mux mode: ALT0 mux port: FLEXCAN2_TX of instance: flexcan2

Page 451
 
Again I am maybe not the best one to answer here.
But one thing I noticed was:
Code:
    CORE_PIN1_CONFIG = 0x12;
Will set pin 1 to = 010 ALT2 — Select mux mode: ALT2 mux port: LPUART6_TXD of instance: lpuart6

Should probably be: 0x10 for 000 ALT0 — Select mux mode: ALT0 mux port: FLEXCAN2_TX of instance: flexcan2

Page 451

tonton81 is right it should be 0x10. Was trying to get Can1 working on pins 22 and 23, but that didn't seem to work. Forgot to put it back to 0x10 when I posted it. Other than that it should work.

Just seems pins 0 and 1 are funny when it comes to assigning alternate pins.

Again my encoder test case seems to work with the other pins tested except for pins 0 and 1.
 
i’ve tested loopback mode and havnt been able to receive even with self reception enabled and listen only modes...
if self reception is not working and the transmit buffers are all filled pending arbitration, its either pin or clocking issues, as those modes do not require bus activity, however, i will say i have a t3.2&3.5 randomly talking to each other over the same bus fine, i set those up before i started the t4 version
 
Maybe post encoder source and I will try to take look...

Maybe dig up rover with encoders...

This was buried in an edit I did. EDIT: If you want to see the Encoder sketch that works on pins 6/7, and 2/3 I just posted it on GitHub, https://github.com/mjs513/WIP

The encoder stuff is pretty much direct from the SDK example. Not the cleanest but just needed something working to test XBAR and the module with before I started on anything with quadrature encoders.
 
I wrote several posts about the need to modify its setting...:rolleyes: (insider)

Ok, its really needed to disable it or switch to write-through - will not work without that.
We have to wait for a official solution by Paul.
In the meantime, you can edit configure_cache() in startup.c:
Code:
    SCB_MPU_RBAR = 0x20200000 | REGION(3); // RAM (AXI bus)
    SCB_MPU_RASR = [COLOR=#ff8c00][I][B]MEM_CACHE_WT[/B][/I][/COLOR] | READWRITE | NOEXEC | SIZE_1M;
Malloc and DMAMEM both use the same memory area -> identical results.
 
Thanks @Frank B,

Yep that got working.

I remember reading about it awhile back, but getting harder to find things in this thread... thought a fix was already in. Wondering now about does it make sense to do dma in spi library,as user might expect to be able to use any memory address for RX or TX locations.
 
Well, "normal" RAM (for variables) is not cached.
OCRAM (HEAP, DMAMEM) is cached. I've proposed a way to make DMAMEM uncached and keep HEAP cached.
If a user wants to use HEAP - well.. he has to learn that there is a cache and DMA does access the underlying RAM, and not the cache.
There are functions to flush the cache in the core.
 
Last edited:
Kurt, in my lib I have a funny effect:
I have to copy the dmasettings twice:

dmatx = dmasettings[0];
dmatx = dmasettings[0];

Nothing else helps - not asm("dmb"), not ("dsb"), not ("isb"), ..all three combined do not help, too. I even tried a delay.
Dmatx is in normal RAM, which is not cached.
I found this only by accident, after hours of trying to identify the problem that restarting the autorefresh always started with the last chunk of data.
As soon I had this line twice, accidentally, it suddenly worked..

Anybody got an idea? :)
 
Frank,
Sounds pretty strange!

Will play some with SPI.transfer code and see how what I need to do... Will keep it simple to start with. And then maybe try to look up what it takes to flush the cache... But right now busy with some other stuff...
 
Kurt: re: DMA/SPI
The best solution I found so far to detect the end of a transfer is the magic Enterprise value:
Code:
 while ((LPSPI4_SR & 0x1701) != 0x1701) {}; //TDF=1, WCF=1, FCF=1, TCF=1

If you use the hardware-CS you migth want to add the MBF flag. It goes LOW shortly after the flags above. I found, for my software-cs it's not needed to wait for it.
 
Last edited:
Bsp

Page 1721:
28.2 Overview
This section provides an overview of the
• NIC-301 (Network Inter-Connect) AXI arbiter IP
The NIC-301 (by ARM Ltd.) is a configurable AXI arbiter between several masters
and slaves. The NIC-301 IP is designed so that many configuration options are
selected at the hardware design stage, determined by SoC characteristics and needs,
while several other configuration options are software-controlled.
This chapter covers in brief the NIC-301 while providing configuration details on the
NIC-301 instances used in the chip. For complete details on the NIC-301 design, see the
ARM specification, AMBA® Network Interconnect (NIC-301) Technical Reference
Manual, version r2p3.


NOTE
The NIC-301 default settings are configured by NXP's board
support package (BSP), and in most cases should not be
modified by the customer. The default settings have gone
through exhaustive testing during the validation of the part, and
have proven to work well for the part's intended target
applications. Changes to the default settings may result in a
degradation in system performance.
Do we have a TODO here ? What is the "BSP"?
 
Hi everyone. Sorry I've been so absent the last couple weeks. Still getting over this cold, but things are starting to return to normal.

On the PJRC business side, Robin & I hired a new person who starts Tuesday, so there too things will soon be back to normal.

Right now I'm reading through the last couple hundred messages I've missed on this thread (while limiting my forum activity to only basic tech support stuff).

Paul - do you have a goal release date for Beta #8?

Yes. I tried to merge all the pending pull requests Thursday & Sunday. Please let me know if I've missed any?

Planning to do some testing and maybe some initial work on the USB stuff, then package up 1.46-beta8 late Monday or early Tuesday.
 
Fetched the latest CORES and it seems good - for what I tested ... micros ...
And 8 port Serial Chaining with no DEBUG_PRINT_STUFF in T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\debug\printf.h to open Serial #4
CROSSPOSTED with Paul - Glad you are feeling better - hope the new staff member up to speed quickly. Beta 8 sounds like fun - my notes above show it isn't broken :)

Paul took the micros() change to cores - if you get that the T4_demo ... Syncron_Micros for fun LED flash and temp reading. On github at 600 MHz - but #define CHANGE_SPEED will cycle [200-800] MHz and works on the T4 I got.

The Cores update gives 1us res for micros and elapsedMicros based on last systick. It demo's the ARM Synchronization primitives - easier to see in Syncron_isr which will run without cores update against IntervalTimer at 1000 or 100 us is anyone wants to look at getting safe (atomic like?) data updates across an _isr without killing interupts [this parallel code may fully not match the working micros code]. Thanks to FrankB for pointing the way on that. It seems to add only a couple/few cycles of overhead - mostly from it forcing data to be re-read when conditional detects interrupt occurrence. In the case of micros() time spent is about the same because of not doing int Off/On.

With that Paul made the unused_interrupt_vector() weak like it was on T_3.x - so I'm going to look into a library with my assert and other tracing tools I started on _T3 to see if being stopped by a fault can expose info on what came before that with output to Serial# port. Hopefully including user input to issue commands [restart, bootloader, ...] - including calling a DUMP() function in user sketch to expose stuff that is too much to print when running.

On T_3.x Paul had things like this to keep Serial alive to allow auto upload:
Code:
  if (SIM_SCGC4 & SIM_SCGC4_USBOTG) usb_isr();
  if (SIM_SCGC4 & SIM_SCGC4_UART0) uart0_status_isr();
Some note and the state of USB Serial suggests this is TBD ...

KurtE for Serial# might this be the equivalent function to move Serial# data when faulted? ::
Code:
HardwareSerial::IRQHandler()
 
Nothing uses GPTn as far as I know ... which goes to Paul's need to have a "timers consumers list" to know what is using which timers (PIT, GPT, QTMR, flexPWM) ... IntervalTimer, Tone, PWM, IRremote ...

Really? Using a "precious" 32bit timer/counter for micros?

My general plan has been to use both GPT to allow up to 10 IntervalTimer instances. The general idea was to configure both for free running mode (0 to FFFFFFFF at 24 MHz) and use the 3 comparators.
 
@Paul
Glad things are back to normal and you are feeling better. If the cold is like anything I had its going to linger a while longer.

@defragster
Tim - Gave your T4_demo ... Syncron_Micros a try the other and was forgot to even check out the micros, was watching the Temp changes as speed changed :) Forgot to tell you too much else was going on.

As for the assert function, you know I gave it a try and was working. But interestingly enough when I was poking around the sdk it had a version of a assert function in one of the other folders, if you want it I can post it.

Mike
 
Yes it was active, and USB is online.. so I don't know the reason.

At very low clock speeds, the internal buses probably can't support USB packets at 480 Mbit/sec.

I believe the USB PHY has a bit to restrict the hardware to only 12 Mbit/sec. We should probably set that if the speed is so slow.
 
...
@defragster
Tim - Gave your T4_demo ... Syncron_Micros a try the other and was forgot to even check out the micros, was watching the Temp changes as speed changed :) Forgot to tell you too much else was going on.

As for the assert function, you know I gave it a try and was working. But interestingly enough when I was poking around the sdk it had a version of a assert function in one of the other folders, if you want it I can post it.

Mike

Temp moves quickly up and down decided to make a thing to see :) - so good PJRC use of board to spread heat (of course this one wider than Teensy) or it wouldn't drop as fast - and the MCU gets busy and warms fast with extra cycles and volts.

I did see your assert_t3 note :) - and I installed the NXP SDK and browsed enough to see they had an ASSERT - I'll go back to it to see if it adds anything or works better. Another ideas for debug - or ways to make faults or show helpful stuff - post or PM.
Code:
void __assert_func(const char *file, int line, const char *func, const char *failedExpr)
{
    PRINTF("ASSERT ERROR \" %s \": file \"%s\" Line \"%d\" function name \"%s\" \n", failedExpr, file , line, func);
    for (;;)
    {}
}
 
USING ALTERNATE DEFINITIONS OF PINS - HOW TO?

Getting myself really confused on this one, trying to read the manual and testing. Looking at PINs 0 and 1 for instance the default is Serial1 (LPUART6). Now if I want to reassign it to XBARA or FLEXCAN. I was looking at the quadrature encoder module and it use the xbara pins for input. Anyway this is the process I think:

1. Turn LPUART6 clock off (CCGR3)
2. Disable the LPUART6 IRQ
3. didn't see a way to update the vtable so guess that stays
4. Update pin configurations, i.e.,
Code:
000 ALT0 — Select mux mode: ALT0 mux port: FLEXCAN2_RX of instance: flexcan2
001 ALT1 — Select mux mode: ALT1 mux port: XBAR1_INOUT17 of instance: xbar1
010 ALT2 — Select mux mode: ALT2 mux port: LPUART6_RX of instance: lpuart6
and sion bit to enable
5. Select input - output modes for pins, i.e.
Code:
IOMUXC_FLEXCAN2_RX_SELECT_INPUT for Flexcan
xbar_connect  (saw this in pwm.c)
6. Configure Flexcan2 or Xbar clocks
7. Enable clocks with CCM_CCGR0 or CCM_CCGR2
8. Almost forgot enable IRQs for XBAR or FLEXCAN2

Still need to work some of the details but just want to see if this makes sense and I am on the right track.

For most of the peripherals, you probably don't need to shut off their clock or fully disable them just to reassign their I/O pins. You DO need to shut off a peripheral if you're going to mess with its clock. I can tell you I managed to lock up the whole chip in strange ways just by messing with the UART clocks while the hardware was enabled. Great caution is needed when fiddling with any "CCM" stuff. So far I've not seen that sort of problem when just messing with the IOMUX settings.

So far, I've only done limited experiments with XBAR, and only stuff inside the chip. You found the xbar_connect function I wrote while working with FlexPWM. Before I figured out how to turn off the fault inputs and properly clear fault status (which was a major frustration getting PWM to work... about 1 month before we started this beta test) I did use that code to control the PWM fault inputs. It did seem to work (and earlier versions you don't see definitely did not work, as evidence by lack of effect on those troublesome fault status bits).

One of the great mysteries of this chip (at least to me) is why NXP didn't route the quadrature decoder signals to any pins, only to XBARA. I'm going to guess it was an oversight. So you have to use the XBAR, just to get pins connected to it. I have not actually done this, but here's my best guess from reading the reference manual.

1: Make sure the relevant bits in IOMUXC_GPR_GPR6 are clear. They're supposed to default to all zeros at reset, so you can probably skip this step if you're not concerned any other code might have messed with that register. If you're going to try to just output from XBAR, then you must set the bit to 1 for whatever physical pin you'll use.

2: Write to the IOMUX register. Whether the SION bit needs to be set is a good question. I really don't know, but my guess is SION should be 0 for XBAR use. If the mux was set to something other than GPIO (5), whether you would shut that peripheral off is a good question. My guess is you can probably ignore that.

3: Write to the input select register, like IOMUXC_XBAR_INOUT17_SELECT_INPUT

4: Then you'd call xbar_connect(), or just write directly to the XBAR register. But I can tell you (and you can see in the code comments) that 8 bit writes do not work to XBAR registers, so you must do 16 bit read-modify-write to set the XBAR connection you want.

Hopefully these 4 steps will get the signal connected to the encoder. Then of course you'll need to configure it. More complicated registers to figure out.....
 
Last edited:
Softwareserial:
Code:
"C:\\Arduino\\hardware\\teensy/../tools/arm8/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fno-exceptions -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1052__ -DTEENSYDUINO=146 -DARDUINO=10808 -DF_CPU=396000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-Ic:\\temp\\arduino_build_958717/pch" "-IC:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "-IC:\\Arduino\\hardware\\teensy\\avr\\libraries\\SoftwareSerial" "C:\\Arduino\\hardware\\teensy\\avr\\libraries\\SoftwareSerial\\SoftwareSerial.cpp" -o "c:\\temp\\arduino_build_958717\\libraries\\SoftwareSerial\\SoftwareSerial.cpp.o"
C:\Arduino\hardware\teensy\avr\libraries\SoftwareSerial\SoftwareSerial.cpp:260:2: error: #error This version of SoftwareSerial supports only 20, 16 and 8MHz processors
 #error This version of SoftwareSerial supports only 20, 16 and 8MHz processors
  ^~~~~
Think I got it working - can someone verify for me. Here are the files new files:
View attachment SoftwareSerial.zip

Thanks

UPDATE: Nevermind - not working tested on pins 8/9 and 10/11 but if someone wants to double check. Not sure what pins are going to be allowed

Found my answer and now I understand the code:
The SoftwareSerial library on Teensy 3.2 is just a compatibility wrapper. It only works if using 2 pins for a real hardware serial port.
So guess the same applies to T4.
 
Last edited:
Status
Not open for further replies.
Back
Top