Teensy 4.0 & 4.1

Discussion and questions about boards that can run MicroPython but don't have a dedicated forum.
Target audience: Everyone interested in running MicroPython on other hardware.
User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Teensy 4.0 & 4.1

Post by Roberthh » Tue Oct 05, 2021 5:55 pm

Thank you for the feedback. Then we will change the files accordingly. I just checked that the mimxrt1020 file works as well for the Teensy boards.
But do not thank me alone. The first huge step of going to a minimal port to supporting all the devices on the boards was done by @alphaFred, and since this year we work on the port together. In my eyes, @alphaFred is way more capable in dealing with that low level coding than me.
About the Arch Mix board: I found a distributor which has them on stock and can deliver fast. So i ordered a pair, such that we can include that in the set of supported board. What has to be done is creating a pins.csv file, adapting the gpio vs device assignments in mpconfigboard.h and testing. Not complicated, just a little tedious.

loboris
Posts: 344
Joined: Fri Oct 02, 2015 6:19 pm

Re: Teensy 4.0 & 4.1

Post by loboris » Tue Oct 05, 2021 6:14 pm

Roberthh wrote:
Tue Oct 05, 2021 5:55 pm
Thank you for the feedback.
Thanks to all who participated in the work on mimxrt port, of course.

It is good to hear you are going to get the Arch Mix board, I think it is quite a good board and the price is very attractive.

BTW, do you have any plans to add the option to build the firmware which runs fro SDRAM? I suppose it should rum faster than from xip qspi flash and with 32MB of SDRAM on many boards it could be a good option.

alphaFred
Posts: 31
Joined: Wed Apr 15, 2020 6:47 pm

Re: Teensy 4.0 & 4.1

Post by alphaFred » Tue Oct 05, 2021 6:38 pm

We already have a PR open for using the SDRAM for the MP heap. However we did not yet implement code execution from SDRAM. It should certainly improve performance
From the top of my head something like that would require a new/modified Linker Script. So this should not be too much overhead in the end. Nonetheless this is something for our backlog I am afraid as I am hoping for my SDRAM PR to finally get merged ☺️.

Next big thing probably will be the release of our own DFU bootloader - excuse my shameless ad 😄.

Anyhow Robert made some performance measurements with moving some parts of MP into the tightly coupled memories which resulted in great performance improvements. So if you need more performance take a look into his repo.

loboris
Posts: 344
Joined: Fri Oct 02, 2015 6:19 pm

Re: Teensy 4.0 & 4.1

Post by loboris » Tue Oct 05, 2021 6:56 pm

alphaFred wrote:
Tue Oct 05, 2021 6:38 pm
We already have a PR open for using the SDRAM for the MP heap. However we did not yet implement code execution from SDRAM.
I'm using Robert's repository and MPy heap on SDRAM works without issues.

Some info about booting from SDRAM can be found here with some instructions and documentations attached. I think it should be relatively simple...

DFU bootloader would be nice.
RT1052/1062 can be flashed using serial connection directly if some boot mode switches are set correctly, For example Arch Mix has all needed swiches exposed on board and can be flashed over USB OTG connector...

alphaFred
Posts: 31
Joined: Wed Apr 15, 2020 6:47 pm

Re: Teensy 4.0 & 4.1

Post by alphaFred » Tue Oct 05, 2021 7:13 pm

Thanks for the link.
The example presented there is using the BootROM to copy your code into SDRAM at startup. That requires you to configure the IVT correctly and probably also DCD to set up the SEMC.

Still it requires changes to the Linker Script because you need to link to SDRAM address range.

For now this design would then no longer work when using my bootloader because the loader will jump to the firmware entry at startup in case it detects a valid firmware. Of course I could be implement a load table and then the same firmware binary would also work with my bootloader.

I have not thought about it yet tbh.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Teensy 4.0 & 4.1

Post by Roberthh » Tue Oct 05, 2021 7:19 pm

DFU bootloader would be nice.
Yes. The intention is to have the same bootloader method on all supported devices. If we have our own bootloader, then the board specific bootloading would only be needed to install the bootloader, at best only once.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Teensy 4.0 & 4.1

Post by Roberthh » Tue Oct 05, 2021 8:56 pm

@loboris: Did you try the Ethernet Port on the VisionSOM-RT module as well? The PHY controller on the base board is the same as on the NXP boards. You can start it with:

from network import LAN
lan=LAN()
lan.active(True)

Then the board should negotiate the speed and get a DHCP address.

loboris
Posts: 344
Joined: Fri Oct 02, 2015 6:19 pm

Re: Teensy 4.0 & 4.1

Post by loboris » Tue Oct 05, 2021 9:13 pm

Roberthh wrote:
Tue Oct 05, 2021 8:56 pm
@loboris: Did you try the Ethernet Port on the VisionSOM-RT module as well? The PHY controller on the base board is the same as on the
It reports an error:

Code: Select all

>>> from network import LAN
>>> lan=LAN()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: PHY Init failed.
>>> 
But something is initialized as the ethernet green led starts blinking (on boot the led is off).

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Teensy 4.0 & 4.1

Post by Roberthh » Wed Oct 06, 2021 5:49 am

The I have to check the connections. How long does it take after calling lan.active(True) until the error message pops up?

loboris
Posts: 344
Joined: Fri Oct 02, 2015 6:19 pm

Re: Teensy 4.0 & 4.1

Post by loboris » Wed Oct 06, 2021 8:36 am

Roberthh wrote:
Wed Oct 06, 2021 5:49 am
The I have to check the connections. How long does it take after calling lan.active(True) until the error message pops up?
The error occurs in the initialization code, so the lan instance is not even created.
Probably the ENET_RESET_PIN and ENET_INT_PIN are wrong (used reset pin, GPIO_AD_B0_09, is connected to the onboard led which goes on on initialization).
Looking at the schematics, I can't find where ENET1-INT/ENET1-RST are connected. I'll try to ask SomLabs for an explanation.
The ethernet works fine in SomLabs's test application preloaded on the module.

Post Reply