Teensy 4.0 First Beta Test

Status
Not open for further replies.
you might read further in that thread about adding asm volatile ("dsb") ; to ISR.

Turned out, that double calling of isr was not an issue for me (in my code isrCount1 and isrCount2 are always the same, apart from rare race condition). maybe because TFLG was polled?
So, I played further
Code:
uint32_t isrCount1=0;
uint32_t isrCount2=0;
void pitIsr()     // 12 interrupts
{
  for (int i = 0; i < 4; i++)
  {
    if (IMXRT_PIT_CHANNELS[i].TFLG == 1) // if channel TFLG is set, clear it
    {
      IMXRT_PIT_CHANNELS[i].TFLG = 1;
      isrCount1++;
    }
  }
  isrCount2++;

}

void pitIsr1()  //48 interrupts
{
  IMXRT_PIT_CHANNELS[0].TFLG = 1;
  isrCount1++;
  isrCount2++;

}

void pitIsr2()  // 24 interruts
{
  IMXRT_PIT_CHANNELS[0].TFLG = IMXRT_PIT_CHANNELS[0].TFLG;
  isrCount1++;
  isrCount2++;

}

void pitIsr3()  //12 interrupts
{
  IMXRT_PIT_CHANNELS[0].TFLG = IMXRT_PIT_CHANNELS[0].TFLG;
  isrCount1++;
  isrCount2++;
  asm volatile ("dsb");
}

void pitIsr4() // 12 interrupts
{
  IMXRT_PIT_CHANNELS[0].TFLG = 1;
  isrCount1++;
  isrCount2++;
  asm volatile ("dsb");

}

void beginPIT(uint32_t cycles)
{
  CCM_CCGR1 |= CCM_CCGR1_PIT(CCM_CCGR_ON);
  PIT_MCR = 0;

  IMXRT_PIT_CHANNELS[0].TCTRL=0;
  IMXRT_PIT_CHANNELS[0].LDVAL = cycles;
  IMXRT_PIT_CHANNELS[0].TFLG = 1;
  IMXRT_PIT_CHANNELS[0].TCTRL = PIT_TCTRL_TEN | PIT_TCTRL_TIE;

  attachInterruptVector(IRQ_PIT, pitIsr2);
  NVIC_ENABLE_IRQ(IRQ_PIT);
}

void setup()
{
  while(!Serial);
  Serial.println("Test_PIT");

  pinMode(LED_BUILTIN,OUTPUT);
  beginPIT(1000*1000L);
}

void loop()
{ static uint32_t loopCount=0;
  digitalWriteFast(LED_BUILTIN, !digitalReadFast(LED_BUILTIN));
  delay(500);
  Serial.printf("%10u %10u %10u %10u\n",loopCount,IMXRT_PIT_CHANNELS[0].CVAL, isrCount1, isrCount2);
  loopCount++;
  isrCount1=isrCount2=0;
}

that is:
pitIsr was called 12 times
pitIsr1 was called 48 times
pitIsr2 was called 24 times
pitIsr3 was called 12 times
pitIsr4 was called 12 times

single polling alone is not enough, either polling all or calling "dsb"
 
DSB is the best way to do this because the other hardware blocks do not have access to CPU cache.
Hopefully this doesn't double post, because I submitted earlier and it appeared to not post.
 
@wwatson - set this up with what seem to be the right updated libraries.

See following post #3454 … Needs HUB linkage

Tested my last used USBHost Logger_Raw example and got it working to see the USB HDD. It starts like this:
Code:
Test logger_RawRead
uSDFS_VER:30_Jun_19_07_17
BUFFSIZE :8192
Dev Type :2:/
File System FS_EXFAT
Free Disk Size -1 clusters
Cluster Size 256 sectors
Sector Size 512 bytes

When I run mscWavPlayer I get no ouput? There is no type of … while (!Serial && millis() < 2200);
I added one and a first print that shows then …. nothing else?
Problem running logger_RawWrite sample - it shows DEV type … then nothing else.

Not sure why my old sample works - but those examples don't?

What version of USBHost_t36 is needed?

<EDIT>: I see it can work - I put the files on a SD FLASH in a USB adapter - and I got the start of the first song - though it is horribly poppy and scratchy.
 
Last edited:
I found out why ... these lines are needed because I plug drives in through a Powered HUB - noticed when the USB Stick w/SD failed moved to HUB.
Code:
#include <USBHost_t36.h>
extern USBHost myusb;
USBHub hub1(myusb);
USBHub hub2(myusb);

Sound is still painfully bad - and it seems to be ignoring the volume knob on the Audio board? I tried two sets of ear buds that have worked before. Also set volume to .5 from .75 and the music is softer - the crackle noise is not?

<edit>: Tried with second Audio board and same sound.

With the USBHub defines added the HDD and SSD I tried before now play and they play just as painfully. Tempo is right - and the Audio is there - but not able to listen to it over noise. I pulled these SDTEST# files direct from PJRC today.

Also note the file I called 'TDINER8.WAV' from the install does not play - must be the wrong format.

@wwatson - set this up with what seem to be the right updated libraries.


When I run mscWavPlayer I get no ouput? There is no type of … while (!Serial && millis() < 2200);
I added one and a first print that shows then …. nothing else?
Problem running logger_RawWrite sample - it shows DEV type … then nothing else.
...
<EDIT>: I see it can work - I put the files on a SD FLASH in a USB adapter - and I got the start of the first song - though it is horribly poppy and scratchy.
 
@Defragster I've not had a ton of time here, got some now, though, but is the SDcard present line connected? Reason is that if it is, it can work on UHS30 which recently had SDcard added to it, although I am guessing that it is using the on-chip SD stuff, and not SPI.
It could then be supported if this is the case, and I need only add the specific support for the MCU's module.
Worse case I could bitbang it? (giggles)
 
@Defragster I've not had a ton of time here, got some now, though, but is the SDcard present line connected? Reason is that if it is, it can work on UHS30 which recently had SDcard added to it, although I am guessing that it is using the on-chip SD stuff, and not SPI.
It could then be supported if this is the case, and I need only add the specific support for the MCU's module.
Worse case I could bitbang it? (giggles)

Probably a good question - that I can't answer :( How can I tell?
I put the SD card in a carrier USB3.0 adapter. The breakout PCB I'm using doesn't have an SD socket connected - so I used the adapter? Not sure if the question is specific to one versus the other?
 
That's why I'm asking.... basically I'd like to know if that line for SDcard (not USB adapter) is connected.
If the 4.0 is EHCI, then UHS3 port should be very easy, since Paul helped in porting that for the 3.6.
 
Okay - from that I get you want the native SD pinned from the bottom of the Teensy 4?

Looking on the back of the T4 card I see 6 pins not GND or 3.3V: DAT[0-3], CLK, CMD. With the USB and SD Off the PCB there are no other MCU lines to the SD card or USB Host hardware.

On the T_3.6 there was at least one other MCU line used to enable the HOST USB chip - not sure if there were others where the SD Socket was PCB mounted?
 
If the 4.0 is EHCI, then UHS3 port should be very easy

It is indeed EHCI.

The main difference is Teensy 4.0 requires cache management. If you use memory from malloc(), it is allocated in cacheable OCRAM. You must call arm_dcache_flush() after writing, and arm_dcache_delete() before reading. If the memory is static allocated, then it's in DTCM which isn't cached and the code for Teensy 3.6 should work as-is.

The register names are slightly different, most prefixed with "USB2_" rather than "USBHS_". Here is a header file I created for USBHost_t36 to allow the code to compile. Maybe this can help when you work with UHS3?

https://github.com/PaulStoffregen/USBHost_t36/blob/master/utility/imxrt_usbhs.h
 
It is indeed EHCI.
Ok, that' a good thing.
The main difference is Teensy 4.0 requires cache management. If you use memory from malloc(), it is allocated in cacheable OCRAM. You must call arm_dcache_flush() after writing, and arm_dcache_delete() before reading. If the memory is static allocated, then it's in DTCM which isn't cached and the code for Teensy 3.6 should work as-is.
UHS3 copies to/from where ever the data comes from. If they are static buffers, this shouldn't be an issue.

The register names are slightly different, most prefixed with "USB2_" rather than "USBHS_". Here is a header file I created for USBHost_t36 to allow the code to compile. Maybe this can help when you work with UHS3?

Yeah, I'll be looking at it sometime today, and see what I can do.
 
@all - Not sure if this has been done before. Could not find anything with forum searches.

Anyway I was able to create a WavFilePlayer that uses uSDFS and MSC. At this time it works with my thumb drives and most Hard Drives. I had one 3.5" Hitachi hard that would not work due to a very low read speed. (Skipping and stuttering). The other seven drives worked. None of the drives would work with a buffer size of 512 bytes. I set it to 1024 bytes and all but one Hard Drive worked properly. The other one needed 8192 bytes. Tried 16384 bytes and the 16GIG thumb drive would not work properly. Again playing with buffer sizes.

If anybody is interested, here is the library. I did not modify the Audio library.
Maybe other drives can be tested with this.

View attachment 16878

@wwatson

Had some time this morning and tried out your mscWavPlayer file. One major problem - sound volume impossibly low. Using a amplified speaker on the audio shield I can't hear anything unless I put the speaker right next to my ear. Then I can hear it playing but as @defraster noted a lot of static and popping sounds. Tried changing some of the audio settings but no luck in getting better volume. Did verify that that the files are good by running my other wavfile player and it worked fine with the same files. BTW I did download the latest GitHub sources
 
SPISettings strangeness??

Here is a little SPI performance sketch that behaves differently if a SPISettings variable is used in SPI.beginTransaction() vs embedded settings.
Code:
// t4 spi
//  bus 528/7  75 mhz  max SPI 75/2 37.5 mhz
// jumper MISO to MOSI for err check

#include <SPI.h>
#define PRREG(x) Serial.print(#x" 0x"); Serial.println(x,HEX)

#define CS 10
#define SPICLOCK 40000000
SPISettings settingsA(SPICLOCK, MSBFIRST, SPI_MODE0);
#define SPI_BUFF_SIZE 1024
uint8_t rx_buffer[SPI_BUFF_SIZE];
uint8_t tx_buffer[SPI_BUFF_SIZE];

void setup() {
  Serial.begin(9600); while (!Serial);
  pinMode(CS, OUTPUT);
  digitalWrite(CS, HIGH);
  Serial.println(); Serial.print(F_CPU_ACTUAL); Serial.print(" ");
  Serial.print(__TIME__); Serial.print(" "); Serial.println(__DATE__);
  SPI.begin();
// ??? pick one
  SPI.beginTransaction(SPISettings(SPICLOCK, MSBFIRST, SPI_MODE0));
 // SPI.beginTransaction(settingsA);
  //LPSPI4_CCR = 1;   // DIV  + 2
  // LPSPI4_TCR = 31;   // frame
  PRREG(LPSPI4_CCR);
  PRREG(LPSPI4_TCR);
  PRREG(LPSPI4_FCR);
  Serial.printf("SPICLOCK %d MHz   CCR freq %.1f MHz\n", SPICLOCK / 1000000, 528. / 7 / ((0xff & LPSPI4_CCR) + 2));
}

void loop() {
  uint32_t t1;
  float mbs;

  for (int i = 0; i < SPI_BUFF_SIZE; i++) tx_buffer[i] = i;
  digitalWrite(CS, LOW);
  t1 = micros();
  SPI.transfer(tx_buffer, SPI_BUFF_SIZE);
  t1 = micros() - t1;
  digitalWrite(CS, HIGH);
  mbs = 8 * SPI_BUFF_SIZE / (float)t1;
  Serial.printf("Tx %d bytes in %d us  %.2f mbs \n", SPI_BUFF_SIZE, t1, mbs);

  // jumper MOSI to MISO
  for (int i = 0; i < SPI_BUFF_SIZE; i++) tx_buffer[i] = i;
  memset(rx_buffer, 0, SPI_BUFF_SIZE);
  digitalWrite(CS, LOW);
  SPI.transfer(tx_buffer, rx_buffer, SPI_BUFF_SIZE);
  digitalWrite(CS, HIGH);
  int errs = 0;
  for (int i = 0; i < SPI_BUFF_SIZE; i++) if (tx_buffer[i] != rx_buffer[i]) errs++;
  Serial.printf("errs %d  [3] %d %d \n", errs, tx_buffer[3], rx_buffer[3]);
  delay(3000);
}

At least when selecting a high MHz (e.g., 40mhz) for the SPI clock. Sketch prints out CCR frequency, 25.1 vs 37.7 MHz

As per my previous response, I have made a version of SPI that moves the work for calculating CCR/TCR into the SPI.beginTransaction code, which is only called if the data contained within a SPISetting passed in is different than the previous call to beginTransaction.

Code is up in the fork/branch: https://github.com/KurtE/SPI/tree/T4_SPISettings_calc

I reran your test case and verified that the speed is the same regardless of which of your two beginTranactions is called...

If no one has an issue, will probably issue PR later...

Kurt
 
@mjs513 - you are using line out to speakers? You added a VOL pot on pin 15 too IIRC? Vol pot on mine has no effect - is that pin brought over to the breakout header? - As noted Code .volume did drop the played sound - but not the noise - so it isn't from over driving.

Sorta good you are seeing the same as I am - I suppose should try playing from Audio board SD socket to know it isn't something else in the system - though it seems it works for @WWatson as putting a music playlist on Teensy with that noise wouldn't be cool with what comes out here :)


To test this MSC>Audio using DIY breakout ( with no T4_SD socket) and T4 so that took the single 7 port serial test offline, but now 30+ hours later the other two T4's sharing their 14 Serial# ports is running perfectly fine!. If the MSC>Audio was working I'd merge that code in to the one T4 and have it run the 7 Serial# test with playing the Audio ...
 
@KurtE
As per my previous response, I have made a version of SPI that moves the work for calculating CCR/TCR into the SPI.beginTransaction code, which is only called if the data contained within a SPISetting passed in is different than the previous call to beginTransaction.

Code is up in the fork/branch: https://github.com/KurtE/SPI/tree/T4_SPISettings_calc

I reran your test case and verified that the speed is the same regardless of which of your two beginTranactions is called...

If no one has an issue, will probably issue PR later
Think there may be a problem. Figured a good test would be to run touchpaint_xpt2046 since it use 2 SPI speeds in its setting. Downloaded your updated SPI lib and loaded/compiled/ran the sketch. The screen stayed white and the no touch available. Ran graphicstest and xpt2046 touchtest separately and both ran as expected just not together.

I redownloaded the SPI master and ran the touchpaint_xpt2046 sketch again and it worked without issue. .

Mike
 
@mjs513 - you are using line out to speakers? You added a VOL pot on pin 15 too IIRC? Vol pot on mine has no effect - is that pin brought over to the breakout header? - As noted Code .volume did drop the played sound - but not the noise - so it isn't from over driving.

Sorta good you are seeing the same as I am - I suppose should try playing from Audio board SD socket to know it isn't something else in the system - though it seems it works for @WWatson as putting a music playlist on Teensy with that noise wouldn't be cool with what comes out here :)


To test this MSC>Audio using DIY breakout ( with no T4_SD socket) and T4 so that took the single 7 port serial test offline, but now 30+ hours later the other two T4's sharing their 14 Serial# ports is running perfectly fine!. If the MSC>Audio was working I'd merge that code in to the one T4 and have it run the 7 Serial# test with playing the Audio ...

Tim, no pot on the audio board - just s/w controlled with a amplified speaker that I can adjust the volume. As a check I did run it from the SD Card on the audio board and it ran without issue but I used the my waveplayer.
 
@KurtE
Think there may be a problem. Figured a good test would be to run touchpaint_xpt2046 since it use 2 SPI speeds in its setting. Downloaded your updated SPI lib and loaded/compiled/ran the sketch. The screen stayed white and the no touch available. Ran graphicstest and xpt2046 touchtest separately and both ran as expected just not together.

I redownloaded the SPI master and ran the touchpaint_xpt2046 sketch again and it worked without issue. .

Mike

Hi Mike,

I updated it again to always update TCR and CCR registers on every call to beginTransaction... Have not tried touchpaint yet as right now setup for ILI9488 and not ILI9341...
Also dog sitting! So right now we have our normal: Laik plas Annie running around but we also have Manny (7 or 8 month shelty )...
 
Hi Mike,

I updated it again to always update TCR and CCR registers on every call to beginTransaction... Have not tried touchpaint yet as right now setup for ILI9488 and not ILI9341...
Also dog sitting! So right now we have our normal: Laik plas Annie running around but we also have Manny (7 or 8 month shelty )...

Hi Kurt

First that solved the problem. Touchpaint working fine now.

My little one Shaya, is upstairs now with my wife's sister so have some time. Know the feeling about dog sitting. When wife gets home from Brazil on Thursday we will be babysitting her daughters puppy - too much energy. But then again wife will be home :)
 
@defragster @mjs513.

I had the same problem at first with the music skipping and clicking. What it turned out to be was the size of the buffer. Unfortunately If it's to big then it can't return the data fast enough from the USB drive. If it's to small like the default 512 bytes it does the same thing. I found as I stated when I first posted this wave player that it still depends on the USB drives read response time and I am sure that there is latency through MSC and FatFs. What I did to make it work was to tune the buffer size for each drive that I tested. It turned out that the best clean response was with buffer sizes between 1024 bytes and 16384 bytes. Most of the hard drives and thumb drives worked well with a 8192 byte buffer size. One Hitachi drive just would not work well.

There are two places that have to be changed. One in 'play_msc_wav.cpp', line 157 and one in 'play_msc_wav.h', line 54. these are hard coded values. They should say 8192 as that gave me the best performance with all my drives.

As far as the volume goes I was using earphones. I have the pot soldered in on my audio board so I un-comented lines 101-103 in 'mscWavPlayer.ino' . Without the pot I just increased the value in line 69.

I hope you guys can make it work on your side.

Back to work I go. Another double. BLEAHHH:)
 
@wwatson - thanks will edit - I didn't see those buffer numbers - I recall notes on sizes - but didn't look beyond sketch. Sort of assumed whatever number on github would be close at least somewhere between SSD>HDD>SD Card.

Volume :: opps - I have pin 15 Serial3 Rx wired to Serial4 Tx - I saw it uncommented in the code but just now checked that … residual connection - Need to take those off.

Suppose you saw the note re: "USBHost HUB" required - adding it doesn't hurt when no Hub of course. And the wait on Serial to make sure any early Error or messages can show.

Will correct and give it a try shortly.
 
@wwatson : It works! Including the volume knob now on the PJRC Beta Breakout >> AS LONG AS BUFFER is over 512 Bytes??? Just me?

Got VOL knob and good play sound going with 1024 byte buffer numbers in both 'src' files. It works well USB SD adapter on host plug, or SD and HDD and SSD on powered HUB. That HDD is a 10 year old 160 GB from a retired laptop - it sounded a bit off w/512 byte buffer?

I have a fresh Seagate 5400 RPM 500 GB drive with 128 MB cache - it works with 1024 byte buffer. I just recompiled it with 16384 byte buffers and all is well. I set buffer here back to 512 Bytes and the Vol Knob is dead.

update> Some 3+ hours later left alone - still playing through the 61 MB's of SDTEST#'s. Using an inductive speaker amp box laying the earbuds on it gives a good sound.
 
Last edited:
Talking back about the cache management, I also had the issue using the SD card library to load content into OCRAM. I just wrap up the file.read in a custom function that reads in everything in chunks of 256 bytes in a buffer on the stack and memcpy to the OCRAM, it works perfectly now. I could fix the code of all the emulators with that change. The atari520st emu is also working fine now. I will push the code on the git end of the week. Sound still missing on T4.

So every time you read from HW to OCRAM and write from OCRAM to HW, think about the cache management!
 
@KurtE

Think I found another issue your SPI update. I was running @wwatson mscWavPlayer using your SPI updated lib and got these errors - prior version compiled and ran:

Code:
  F:\arduino-1.8.9\hardware\teensy\avr\libraries\SD\utility\Sd2Card.cpp:25:20: error: no matching function for call to 'SPISettings::SPISettings()'

static SPISettings settings;
                    ^

In file included from F:\arduino-1.8.9\hardware\teensy\avr\libraries\SD\utility\Sd2Card.cpp:21:0:

F:\arduino-1.8.9\hardware\teensy\avr\libraries\SPI/SPI.h:1039:2: note: candidate: SPISettings::SPISettings(uint32_t, uint8_t, uint8_t)

  SPISettings(uint32_t clockIn, uint8_t bitOrderIn, uint8_t dataModeIn) :
  ^

F:\arduino-1.8.9\hardware\teensy\avr\libraries\SPI/SPI.h:1039:2: note:   candidate expects 3 arguments, 0 provided

F:\arduino-1.8.9\hardware\teensy\avr\libraries\SPI/SPI.h:1037:7: note: candidate: constexpr SPISettings::SPISettings(const SPISettings&)

 class SPISettings {
       ^

F:\arduino-1.8.9\hardware\teensy\avr\libraries\SPI/SPI.h:1037:7: note:   candidate expects 1 argument, 0 provided

F:\arduino-1.8.9\hardware\teensy\avr\libraries\SPI/SPI.h:1037:7: note: candidate: constexpr SPISettings::SPISettings(SPISettings&&)

F:\arduino-1.8.9\hardware\teensy\avr\libraries\SPI/SPI.h:1037:7: note:   candidate expects 1 argument, 0 provided
 
Thanks@mjs513...

I will hack it up some more ;) Actually I was thinking of backing off a little on it... That is I will probably cross between old/new... That is I only need to keep the _clock version raw in the SPISettings... that bitorder/datamode can be processed like before and saved in a already processed TCR register value.

Will have the new cross version soon... Assuming no 4 legged interference :D
 
@mjs513 - Pushed up yet another version of SPI. As I mentioned, this time it is half way between old/new... That is bitOrder and dataMode are handled within constructor of SPISettings (tcr setting). only the clock (ccr setting) is dealt with in the call to SPI.beginTransaction.

Also put back in the constructor with no parameters... Which now compiles :eek:
 
@mjs513 - Pushed up yet another version of SPI. As I mentioned, this time it is half way between old/new... That is bitOrder and dataMode are handled within constructor of SPISettings (tcr setting). only the clock (ccr setting) is dealt with in the call to SPI.beginTransaction.

Also put back in the constructor with no parameters... Which now compiles :eek:

@KurtE

Just retest touchpaint on the ILI9341 still worked with your changes. Recompiled and ran the mscWavPlayer sketch and it worked as well. Looks like that may have got it :)
 
Status
Not open for further replies.
Back
Top