Teensy 4.1 Beta Test

[Frank B]

Whew, that's a big relief.

I'm feeling pretty good about wrapping up 1.52. Anyone see any issues that should block a full non-beta release?

Is the T4.x Audio-PWM output disabled? If not, that should be done before a release.

[mjs513]

@PaulStoffregen and others

Have a question on PSRAM usage: Is there a need or desire to use PSRAM for SPIFFS or should we leave SPIFFS for FLASH only? Thoughts?

[kd5rxt-mark]

Whew, that's a big relief.

I'm feeling pretty good about wrapping up 1.52. Anyone see any issues that should block a full non-beta release?

@PaulStoffregen:

Here's a post relating to the "wires[w2] is null" error that can be experienced when using filters in the Audio System Design Tool for Teensy Audio Library GUI. Maybe it has an easy fix . . . any chance that could make it into 1.52 ??

https://forum.pjrc.com/threads/60859...l=1#post239080

Mark J Culross
KD5RXT

[PaulStoffregen]

Is there a need or desire to use PSRAM for SPIFFS or should we leave SPIFFS for FLASH only?

I personally don't see much need to use PSRAM as a filesystem. Maybe other people do?

[PaulStoffregen]

the "wires[w2] is null" error that can be experienced when using filters in the Audio System Design Tool for Teensy Audio Library GUI. Maybe it has an easy fix . . . any chance that could make it into 1.52 ??

No, definitely not messing with the design tool for 1.52. The last thing I want to do when we've just released new hardware and really need to make a non-beta release is dive down a deep Javascript hole! While I can muddle my way through Javascript projects, it's definitely not one of my main languages.

But after 1.52, I'm definitely going to put some time into fully updating the design tool for the many new objects 1.52 and other recent releases have added, and document the pins and other details for Teensy 4.0 in all the existing ones. I really can't make any promises on fixing deep bugs in the JS code. I didn't even write the import feature. It was contributed (by someone with a lot more JS experience than me).

[Frank B]

@PaulStoffregen:

Here's a post relating to the "wires[w2] is null" error that can be experienced when using filters in the Audio System Design Tool for Teensy Audio Library GUI. Maybe it has an easy fix . . . any chance that could make it into 1.52 ??

https://forum.pjrc.com/threads/60859...l=1#post239080

Mark J Culross
KD5RXT

I think you can motivate people to fix the bug by creating a minimal example where the import does not work.
If you have to identify the bug in dozens of lines that are imported, it is demotivating.

I don't really want to - but maybe I'll invest half an hour to see what exactly it is.
If I have a minimal example.

Please use the other thread.

[kd5rxt-mark]

I think you can motivate people to fix the bug by creating a minimal example where the import does not work.
If you have to identify the bug in dozens of lines that are imported, it is demotivating.

I don't really want to - but maybe I'll invest half an hour to see what exactly it is.
If I have a minimal example.

Please use the other thread.

@Frank B:

Did you actually look at the post that was linked ?? If you did, you would clearly see that it includes the import text which shows the problem (at the top) & the import text which can be used to work around the problem (at the bottom) & more specifically, it clearly identifies exactly what condition (leaving the low-pass filter output unconnected) causes the problem to be reported.

As for using the other thread, @flashburn has already posted there regarding this same issue. With my post (here), I was answering the specific question that @PaulStoffegren posted, asking if there's anything else to be considered before fully releasing 1.52 (to which he gave a very clear reply - thanks Paul, I fully understand !!).

I don't really consider it my place to "motivate" anyone, especially since I know for certain that I don't have sufficient skills to make many contributions myself (this fix & probably very few others) . . . I'm just reporting the facts as I have determined them, to the best of my ability.

Mark J Culross
KD5RXT

[Frank B]

yup, several times (together with flashburn) the last days.
Ok, i had seen flashburn example which is very long.

I'll take a look, later.
(And I dont consider it my place to "fix bugs" for others I do what I like to do here.)

[PaulStoffregen]

I replied on that thread. Let's continue this discussion about the design tool bug on that thread, a several days *after* Teensyduino 1.52 is released.

I also have about 100 web pages that need updating for Teensy 4.1, and many of them were never even updated for Teensy 4.0. Please understand that website update work is a much higher priority that fixing this import bug in the design tool. I really won't be able to do any Javascript hacking until I've cleared a lot of the documentation backlog.

[PaulStoffregen]

Is the T4.x Audio-PWM output disabled? If not, that should be done before a release.

Opps, forgot about the PWM stuff. I disabled it just now.

https://github.com/PaulStoffregen/Au...84efa2a16ef8b8

Hope this is ok?

[MichaelMeissner]

@Michael, a question: What means the "weak" attribute here?

I've seen it for functions only, so far.

It is similar to functions. An extern variable declared weak is normally treated as an external reference. I.e. the definition of the variable must be in some other module.

However, if the linker doesn't find the value, it uses the NULL address (0x0) as the address of the variable. This test makes sure the address is non-null (i.e. the variable is defined by the core library):

  if (&external_psram_size)

[MichaelMeissner]

I replied on that thread. Let's continue this discussion about the design tool bug on that thread, a several days *after* Teensyduino 1.52 is released.

I also have about 100 web pages that need updating for Teensy 4.1, and many of them were never even updated for Teensy 4.0. Please understand that website update work is a much higher priority that fixing this import bug in the design tool. I really won't be able to do any Javascript hacking until I've cleared a lot of the documentation backlog.

Great! It will be good to get the official documentation updated. Besides adding 4.0 and 4.1 stuff, it may be time to more clearly segregate the Teensy 2.x information. I assume, you have plenty of things you know you need to change already, but if you want a reviewer, I can certainly do that.

[KurtE]

In theory the _malloc_r interface in newlib allows you to create a base pointer for doing malloc like allocations:

2.23 malloc, realloc, free—manage memory
Synopsis

#include <stdlib.h>
void *malloc(size_t nbytes);
void *realloc(void *aptr, size_t nbytes);
void *reallocf(void *aptr, size_t nbytes);
void free(void *aptr);

void *memalign(size_t align, size_t nbytes);

size_t malloc_usable_size(void *aptr);

void *_malloc_r(void *reent, size_t nbytes);
void *_realloc_r(void *reent, 
    void *aptr, size_t nbytes);
void *_reallocf_r(void *reent, 
    void *aptr, size_t nbytes);
void _free_r(void *reent, void *aptr);

void *_memalign_r(void *reent,
    size_t align, size_t nbytes);

size_t _malloc_usable_size_r(void *reent, void *aptr);

Thanks @MichaelMeissner - From what I can deduce from what documentation I have seen so far is that these functions are more setup to be more safe (re-entrant)
Some of the place up on the web just have things like _malloc_r(p_reent, size) { return malloc(size); }

Although some of the reent structure in the non-small mode looks like maybe it contains some data structures associated with malloc...

Will take more of a look later. But this may be beyond my pay grade.

[MichaelMeissner]

Thanks @MichaelMeissner - From what I can deduce from what documentation I have seen so far is that these functions are more setup to be more safe (re-entrant)
Some of the place up on the web just have things like _malloc_r(p_reent, size) { return malloc(size); }

Although some of the reent structure in the non-small mode looks like maybe it contains some data structures associated with malloc...

Will take more of a look later. But this may be beyond my pay grade.

Yes, the _r stuff is for re-entrant code, but I didn't know if we could use the framework for separate heaps. I would imagine however, when the dual-core Teensy comes out that Paul has talked about, we may need to revisit re-entrant stuff.

I opened up a new thread about this:

• https://forum.pjrc.com/threads/60879...psram?p=239281

[manitou]

@PaulStoffregen and others

Have a question on PSRAM usage: Is there a need or desire to use PSRAM for SPIFFS or should we leave SPIFFS for FLASH only? Thoughts?

flash only should be good enough

[PaulStoffregen]

I really wanted to have a malloc_extmem() function in 1.52. But time has run out, at least for 1.52. Likewise, I want to support initialized variables, but messing with the linker script so close to a release is insanity.

I absolutely do want to include this in 1.53. Normally my goal is a new release every 3 months, or when a new version of Arduino is released. But for 1.53, my hope is to release in about 4 to 6 weeks, with the last week or two being a feature freeze.

In other news, we're starting to send the 1st production batch boards to people on the msg #1 list who didn't get an early board. Robin says 42 are shipping this morning. Several more have "something complicated" and will probably ship tomorrow or early next week. If you're on the list and don't have an early board and didn't get an email from me, or haven't responded yet, now's the time to contact me so we can get you one of these production boards.

[manitou]

I committed this change to the startup code to default to 88 MHz.

Seems like we've been successful with 132 MHz, but I just noticed in PSRAM data sheet it says 133 MHz max, but if you are doing a "burst command across a page boundary" (?) the max is 84 MHz.

[KurtE]

I really wanted to have a malloc_extmem() function in 1.52. But time has run out, at least for 1.52. Likewise, I want to support initialized variables, but messing with the linker script so close to a release is insanity.

Yep - totally understand, although you could probably quickly hack in a Quick and dirty version of malloc_extmem;

Something like:

uint8_t *extmem_next_free;  // set in startup NULL if we don't have external memory
uint8_t *malloc_extmem(size_t cb_alloc) {
    if (!extmem_next_free) return nullptr;
    uint8_t *ret_val = extmem_next_free;
    extmem_next_free += cb_alloc;
    retun ret_val;
}
void free_extmem(char *p) {
    // we don't do any free yet
}

Obviously one could choose void* instead of char*... One could also maybe setup that all allocations are rounded up to some size 16 or 32?

[PaulStoffregen]

Yes, that's part of my reasoning for not pushing beyond 88 MHz in this first release, even though 132 MHz appears to work. I'm pretty sure but not 100% confident that the buffer scheme in the FlexSPI controller prevents crossing a 1K page.

I want to stay overly conservative for 1.52. Then we can push to higher clocks for 1.53. If faster clocks cause some unexpected problem, we'll be able to point people back to the known-good 1.52 version.

[PaulStoffregen]

although you could probably quickly hack in a Quick and dirty version of malloc_extmem

Oh that's tempting. But I really want to finalize 1.52 in the next 24 to 48 hours.

If you can retest libraries and any large, complicated programs with 1.52-beta5 (ideally with the FlexSPI2 clock speed patch), please, now's the moment for as much testing as possible.

After 1.52, my hope is to focus on documentation for several days, and then get as much of this stuff that couldn't make 1.52 into a first 1.53 beta.

[mjs513]

@PaulStoffregen

Paul playing around with the pad configurations to see if I could get the FLASH and PSRAM working without errors at higher clock speeds without errors. Think I did but could use a double check. I changed the settings to:

	// initialize pins
	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_22 = 0x0110F9u; /* Slew Rate Field: Fast Slew Rate
                                                 Drive Strength Field: R0/7
                                                 Speed Field: max(200MHz)
                                                 Open Drain Enable Field: Open Drain Disabled
                                                 Pull / Keep Enable Field: Pull/Keeper Enabled
                                                 Pull / Keep Select Field: Keeper
                                                 Pull Up / Down Config. Field: 100K Ohm Pull Down
                                                 Hyst. Enable Field: Hysteresis Enabled */
	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_23 = 0x0110F9u; 
	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_24 = 0x0110F9u; 
	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_25 = 0x0110F9u; 
	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_26 = 0x0110F9u; 
	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_27 = 0x0110F9u; 
	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_28 = 0x0110F9u; 
	IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_29 = 0x0110F9u;

got them from the SDK. I ran the memTest sketch at 960Mhz with no errors - all tests passed!

EXTMEM Memory Test, 8 Mbyte
 CCM_CBCMR=B5AE8304 (88.0 MHz)
testing with fixed pattern 5A698421
testing with pseudo-random sequence, seed=2976674124
testing with pseudo-random sequence, seed=1438200953
testing with pseudo-random sequence, seed=3413783263
testing with pseudo-random sequence, seed=1900517911
testing with pseudo-random sequence, seed=1227909400
testing with pseudo-random sequence, seed=276562754
testing with pseudo-random sequence, seed=146878114
testing with pseudo-random sequence, seed=615545407
testing with pseudo-random sequence, seed=110497896
testing with pseudo-random sequence, seed=74539250
testing with pseudo-random sequence, seed=4197336575
testing with pseudo-random sequence, seed=2280382233
testing with pseudo-random sequence, seed=542894183
testing with pseudo-random sequence, seed=3978544245
testing with pseudo-random sequence, seed=2315909796
testing with pseudo-random sequence, seed=3736286001
testing with pseudo-random sequence, seed=2876690683
testing with pseudo-random sequence, seed=215559886
testing with pseudo-random sequence, seed=539179291
testing with pseudo-random sequence, seed=537678650
testing with pseudo-random sequence, seed=4001405270
testing with pseudo-random sequence, seed=2169216599
testing with pseudo-random sequence, seed=4036891097
testing with pseudo-random sequence, seed=1535452389
testing with pseudo-random sequence, seed=2959727213
testing with pseudo-random sequence, seed=4219363395
testing with pseudo-random sequence, seed=1036929753
testing with pseudo-random sequence, seed=2125248865
testing with pseudo-random sequence, seed=3177905864
testing with pseudo-random sequence, seed=2399307098
testing with pseudo-random sequence, seed=3847634607
testing with pseudo-random sequence, seed=27467969
testing with pseudo-random sequence, seed=520563506
testing with pseudo-random sequence, seed=381313790
testing with pseudo-random sequence, seed=4174769276
testing with pseudo-random sequence, seed=3932189449
testing with pseudo-random sequence, seed=4079717394
testing with pseudo-random sequence, seed=868357076
testing with pseudo-random sequence, seed=2474062993
testing with pseudo-random sequence, seed=1502682190
testing with pseudo-random sequence, seed=2471230478
testing with pseudo-random sequence, seed=85016565
testing with pseudo-random sequence, seed=1427530695
testing with pseudo-random sequence, seed=1100533073
testing with fixed pattern 55555555
testing with fixed pattern 33333333
testing with fixed pattern 0F0F0F0F
testing with fixed pattern 00FF00FF
testing with fixed pattern 0000FFFF
testing with fixed pattern AAAAAAAA
testing with fixed pattern CCCCCCCC
testing with fixed pattern F0F0F0F0
testing with fixed pattern FF00FF00
testing with fixed pattern FFFF0000
testing with fixed pattern FFFFFFFF
testing with fixed pattern 00000000
 test ran for 35.31 seconds
All memory tests passed :-)

[Frank B]

Yup, those configurations are useful.
I use it for the opposite case. The CPU emits noise which is not good for a SDR. So i set some pins (SPI and I2S) to slower settings, which reduces the EMI a little bit.
(And all other pins - even the unused/undefined in Teensyduino! are set as outputs to gnd)

[defragster]

Using 1.52 B5's lower speed PSRAM the logger I hacked fills 3.1 MB buffer with 16 bytes of data at 200,000 _isr() samples/sec in 983.02 mSec. { it had an 16 bit uint for array index that broke at 1MB }

With those _isr() samples all the data is parsed ( not written ) for continuity in 196.67 mSec using the faster speed PSRAM (133Mhz) the parsing takes 113.53 mSec - during 200K _isr() logging.

In both cases the data parses/tests to be good. As it does with the following change.

Just edited the struct to the following and buffer grew to 3.34MB (0x3300000) to hold the same number now larger. They are packed so will be 17 bytes { removing the packed pushes buffer to 3.93 MB } and that 17 byte size will repeatedly cross some boundaries in 3.34MB:

struct datrec {
  uint32_t millitime;
  uint32_t microtime;
  uint32_t DWTCount;
  uint32_t byteswritten;
  char skip_me;
} __attribute__((packed));

[mjs513]

Yep - totally understand, although you could probably quickly hack in a Quick and dirty version of malloc_extmem;

Something like:

uint8_t *extmem_next_free;  // set in startup NULL if we don't have external memory
uint8_t *malloc_extmem(size_t cb_alloc) {
    if (!extmem_next_free) return nullptr;
    uint8_t *ret_val = extmem_next_free;
    extmem_next_free += cb_alloc;
    retun ret_val;
}
void free_extmem(char *p) {
    // we don't do any free yet
}

Obviously one could choose void* instead of char*... One could also maybe setup that all allocations are rounded up to some size 16 or 32?

@KurtE
I can give this a try - do I put it in startup.c? Have the perfect test for it.

[defragster]

@PaulStoffregen

Paul playing around with the pad configurations to see if I could get the FLASH and PSRAM working without errors at higher clock speeds without errors. Think I did but could use a double check. I changed the settings to:

@mjs513 - Dropped that change in startup.c and the log test here seemed to run okay.