-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Teensy 4.0 and 4.1 #30204
Comments
Good progress reported from Bernard Kraemer: nxp_hal issue Ethernet SD card SPI/CAN/PWM optional Flash/RAM on 4.1 USB OTG /USB host GPIO issue As promised I started an example application located here. Readme will follow. Maybe someone can check it and give some feedback. |
I tried: "That means you can just take the teensy4-folder from my zephyr-clone, place it at the correct place in your local zephyr installation and you should be ready to go." And then I tried: Output: I mean, it does exist:
Any idea? |
|
2 Bugs:
But anyway the Blinky sample compiles but seems to be broken. I'll have a look... |
ok got it. My code cleanup from yesterday was somewhat too fast (and maybe too late in the evening ;-). Yesterday I removed this little part from
But this defines where the applications standard output goes - e.g. printk() - goes. My example application maps this output to usb and didn't show this bug, so I ran into the trap. I just pushed a bugfix: |
Still not working: ufechner@builder:~/zephyrproject/zephyr$ west build -p auto -b teensy40 samples/basic/blinky Any idea? |
Most likely you've not set the environment variables for the required build system. See https://docs.zephyrproject.org/latest/getting_started/toolchain_3rd_party_x_compilers.html#gnu-arm-embedded for more information. My ones look like this:
|
But do I need a 3rd party compiler? I have installed and setup zephyr-sdk-0.11.4 . |
Some progress:
The following command works: Building for the board teensy40 fails, though:
Any idea? |
When using the target mimxrt1060_evk (which uses the same CPU), I get the following memory usage report:
So perhaps the memory resource definition for the board teensy40 is wrong? I checked the file teensy40.dts, and there is indeed no SRAM defined. Well, the board has no external SRAM, only OCRAM (on chip RAM). That should be good enough. The question is, how to convince the blinky example to use OCRAM or DTCM instead of SRAM... |
I tried the example from https:/bdkrae/zephyr_teensy4_test : west build -p -b teensy40 samples/zephyr_teensy4_test More or less the same problem:
See also: https://lists.zephyrproject.org/g/users/message/2034?p=,,,20,0,0,0::Created,,ocram,20,2,0,74673781 |
Hmm, weird. When I compile the blinky sample for teensy40 it looks like this (and works pretty fine):
But yes, it also states SRAM which is actually not present. I think I'll try the sdk toolchain tomorrow since this looks like the common workflow and in addition my compiler version is outdated. |
It looks as if your toolchain is renaming DTCM to SRAM ... How this can be achieved was described here: https://lists.zephyrproject.org/g/users/message/2034?p=,,,20,0,0,0::Created,,ocram,20,2,0,74673781 But the Kconfig option DATA_DTCM does not exist any more in the current version of Zephyr ... |
Since I'm working on Mac the Zephyr-SDK is not available. I installed GNU 9.2.1 which is nearly the one that Zephyr-SDK uses. Despite some warnings the build succeeds. So I suggest to focus on the blinky sample to solve this issue. When I look at @ufechner7´s build output for this I'm confused about three things:
This SRAM line in the memory usage result is kind of funny. It seems that either ITCM section is renamed to SRAM (which is the standard behavior), or the OCRAM section is renamed to SRAM if I add |
If I add CONFIG_DATA_OCRAM=y to file teensy40_defconfig I get the following error message:
Perhaps you are using a different branch of zephyr than I do? ufechner@builder:~/zephyrproject/zephyr$ git status What is your output of the command: I have no hits. This means I do not have this Kconfig section anywhere: |
Finally it works 😃 . I had to switch to the stable branch of zephyr: cd zephyrproject/zephyr/
|
But the next step doesn't work yet:
|
To flash I currently use teensy_loader_cli tool. You can find your hex-file there: |
I can confirm that the following steps work for me:
So I am able to build a project and program the board. 😄 |
Next steps:
Does this make sense? |
Hello @ufechner7 and @bdkrae , I am also interested in supporting Zephyr for the Teensy 4.1. I also used the teensy_loader_cli: It was not stable and frequently error'd that it could not get permission to the usb port which required a minor edit to the source - I'll document that. I ran a configuration to use the shell via the usb port. My interest is in enabling the i2c ports. I have an i2c analyzer to test it so I would like to contribute to this project. After that, I'd like to test SPI, then PWM. |
Hello @ericrabinowitz, nice to hear, help is welcome. For the i2c I've already added (but not tested) the pin multiplexing sections to pinmux.c, so you should be able to activate it by stating a section in the teensy41.overlay for your application, as well as Little update from my side: |
Created a fairly complete documentation how to build and burn a basic example for Teensy 4.0 on Ubuntu: https:/ufechner7/zephyr_teensy4_test Tricky: cmake must be neither too new nor too old. And you need the 2.4 branch of Zephyr. Is this still true? |
I updated my zephyr-fork and rebased the teensy4-branch. This brought up the SRAM problem mentioned above. Proposed solution is pushed to the branch. So the teensy4 board should now run with latest zephyr code. Some thoughts about RAM placement It seems that Zephyr always needs a memory region named sram. This line in
In the build results this chosen memory (e.g. OCRAM) is then renamed to sram:
Without additional code on application level, all stuff will be located in this "default" memory region. Although it may not be the best solution in terms of performance, I propose to set OCRAM section as chosen sram because of its size (768kB) and simplicity in use. Also this provides a good starting point for optional app level code-and-data-relocation which gives detailed control about RAM locations. To be able to use this function Ethernet on Teensy 4.1 Ethernet interface is working now. I tested with various zephyr samples (dhcp, socket echo, html-server, ...), all compile and work without problems. Unfortunately it needs additional code in nxp-hal repository, see here. |
Congrats for fixing two difficult issues! Question: Did you already create a pull request for your nxp-hal patch? |
I created a second tutorial/ example on how to use the Zephyr shell with Teensy 4.0: https:/ufechner7/teensy4_shell |
Checked the CAN sample. After adding a can-primary define to With flexcan3 the sample doesn't work. But since this peripheral seems to have some special status acc. to manual, this seems acceptable (maybe a HAL issue). |
Any idea where this warning might be coming from: Do you also see it when running your example? |
I updated https:/ufechner7/teensy4_shell . I added sections about custom commands and inter thread communication. Other topic: I can confirm that the flag GPIO_PULL_UP doesn't work . This is a missing feature or bug, not in the board definition, but in the driver for the CPU. It should be processed in the file drivers/gpio/gpio_imx.c , but it isn't. Current code: if ((flags & (GPIO_SINGLE_ENDED
| GPIO_PULL_UP
| GPIO_PULL_DOWN)) != 0U) {
return -ENOTSUP;
} In the file fpio_stm32.c you find this code: if ((flags & GPIO_PULL_UP) != 0) {
*pincfg |= STM32_PINCFG_PULL_UP;
} else if ((flags & GPIO_PULL_DOWN) != 0) {
*pincfg |= STM32_PINCFG_PULL_DOWN;
} else {
*pincfg |= STM32_PINCFG_FLOATING;
} We need something similar for the imx CPU.
|
Yes, I also can see it. Most samples regarding usb use |
Hi! I was wondering if one of you two have some work done on the SPI? Btw thank you for all your work on this board, it will be a really nice add-on to the projet! |
SPI is next on my ToDo list... No guarantee, of course, but holidays in shutdown give some room for coding and testing... |
I did some progress on SPI, very simple (and poorly tested) sample is here. I also updated pinmux.c in the teensy4 board defs. Again there is some side load:
I will ask the nxp experts why this is missing, probably there is a reason. It´s included in most other soc´s declared in the same file. |
#26428 shows the answer for the SPI issue. |
Well, is it more complicated to add it here? |
This branch adds support for the teensy4 board family (Teensy 4.0 and Teensy 4.1). The configuration is based on the mimxrt1060_evk, the [teensy project documentation](https://www.pjrc.com/store/teensy41.html) and the IMXRT1060 reference manual. Code is successfully tested with the following sample code: blinky pilosophers hello_world drivers/can Example applications using many peripherals can be found here: [https:/ufechner7/zephyr_teensy4_test](https:/ufechner7/zephyr_teensy4_test) [https:/bdkrae/zephyr_teensy4_test](https:/bdkrae/zephyr_teensy4_test) Teensy 4.1 Ethernet will only work if zephyrproject-rtos/hal_nxp#71 is accepted. Closes zephyrproject-rtos#30204. Signed-off-by: Bernhard Krämer <[email protected]>
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time. |
How can I reopen this issue? I mean, there is a commit that might close it, but that is not merged yet, it is waiting for review. |
can somebody confirm if SPI is now supported and what version of Zephyr is required for it. Or is it still being worked on? We are considering using Zephyr but we need SPI support as our custom board has various SPI chips , ADC extensions, thermocouples and DAC? |
@Stevenlawrencehoriba We've been using a Teensy 4.1 with zephyr to interface with sensors via the LPSPI peripheral and have so for almost 2 years, so any recent release should support that 👍 |
Please provide official support for Teensy 4.0 . See: https://www.pjrc.com/store/teensy40.html
This board is sold in large quantities, mainly to hobbyists, but also to small companies. Normally it is used with Arduino Software & Libraries . Making Zephyr available for this board would increase the user base of Zephyr and thus the Zephyr ecosystem.
For the user it would allow to run more demanding software on the board, and it would it make it easier to switch to a different board if required.
I ask for support here because while having the time and capabilities to test the Teensy support of Zephyr, I do not have the skills (yet) to implement it. Further more this would be a good place to discuss how to implement the support. A proof-of-concept is already available (see: end of this thread https://forum.pjrc.com/threads/50241-(Question)-zephyr-support-for-teensy-3-x and https:/bdkrae/zephyr/tree/teensy4-branch/boards/arm/teensy4 ).
The text was updated successfully, but these errors were encountered: