MicroPython Forum (Archive)

When I implemented it I tested it as well. Maybe not with every mimxrt board on my desk. I'll repeat that. Anyhow, it should not lock up. It should time-out.

Well, it looked like a later change stopped the ticks-us timer in this case. Keeping it running solves the problem, but may cause incorrect readings.

As a first response, I have placed a new version at https://github.com/robert-hh/Shared-Stuff. I'll make a PR as well, but that may take a while to get processed.

Roberthh wrote: ↑

Wed Nov 10, 2021 12:55 pm

As a first response, I have placed a new version at https://github.com/robert-hh/Shared-Stuff. I'll make a PR as well, but that may take a while to get processed.

@Roberthh

Your firmware v1.17-138-gff4f1f3ab-dirty dated 2021-11-10 works a treat...

Thx a Mill...

John

While working on my FreeRTOS port (which is now mostly completed), I've developed my own bootloader program.
The main reason was that I need the possibility to upgrade the firmware on remote location (over GSM connection to Internet).
The developed bootloader provides this functionality (and works quite well), but it can also be used as a convenient way to flash the new firmware to the board over CDC/ACM connection available on every board (the MicroPython REPL works over the same connection).

The bootloader has to be programmed to the Flash only once, after that the new firmware can be loaded over the same port used for REPL.
In addition it adds the possibility to have tho different firmware versions, increased security, etc.
The only change needed in the MicroPython firmware build process is that it needs to be linked for start address 0x60010000 (or higher).

For comunicating with the bootloader and loading the firmware I've developed a program in Python which works well both on Linux and Windows (tested on Ubuntu 20.04 and Windows 10).

If anyone is interested, more information, the sources and the prebuilt firmwares can be found on GitHub (iMX_RT10XX_bootloader).
The documentation is not yet complete, but I'll will update it soon.
I'could also post a pull request with needed changes in linker and Makefile.

Thank you. So you ran into the same inconvenience we had with the Teensies - in that firmware upload erases the file system. @alphafred has developed a generic bootloader for the i.MX RT devices, which uses dfu-util for firmware upload. It works fast and well. Even if it is in principle independent from the firmware, is is bundled with the firmware, such there is only one file per device to maintain. That is easier to deal with and avoids confusion. The additional file size is negligible. The PR for that is about to be made.

Nice work. I can definitely see that you tweaked it to your needs

I have a question about your A/B firmware setup. Do you use firmware which is compiled for RAM only or do you generate two images, linked for the respective locations or have you played around with position independent code?

alphaFred wrote: ↑

Mon Nov 22, 2021 9:36 pm

I have a question about your A/B firmware setup. Do you use firmware which is compiled for RAM only or do you generate two images, linked for the respective locations or have you played around with position independent code?

I'm generating two XIP firmware images, one linked for the lower part of the firmware reserved Flash area (at 0x60010000) and the other for the upper half (at 0x60110000). VFS is at 0x60210000. The firmware parts can, of course be larger (some of my Micropython firmwares are almost 2MB).
I mostly use MicroPython on remote measurement stations where upgrading the firmware on-site is impractical and it must be performed via Internet (GSM).
The main purpose of the bootloader is that I can download the firmware upgrade directly from MicroPython (I have an OTA module for that purpose). Depending on which part of the flash MicroPython is running, the image for the other part is downloaded, checked and the bootloader parameters are adjusted to run from that part after reset. The upgrade must be absolutely secure, that is the reason why SHA256 is used for checking the firmware integrity.
On RT106x it could be done in a simpler way (without the bootloader), but I haven' tested it yet.

i.MXRT1060 provides one feature to remap FlexSPI1 and FlexSPI2 address, that means it can use the
same address map to different flash physical address, which is interfaced by FlexSPI1 and FlexSP2.

Anyway, having the same firmware for both RT1052 and RT1062 is for now better option (for my needs).

@Mike Teachman How is your progress with I2S support. I hope that you use for better portability the NXP libraries and not code from PJRC. Did you see that there are also module examples by NXP? They are provided in their SDK Packages that you can request from the NXP web sites. They have a lot of information there, kind of overwhelming.

It's a good time for an update. Here is the progress so far:
1. A skeleton of the I2S class is working in the machine module. I2S objects can be created.
2. Using NXP example code I've been able to initialize the I2S peripheral, initiate a data transfer to the I2S peripheral using DMA, and get a DMA callback when the data transfer is complete. The example I found is excellent and closely resembles how DMA is used on the STM32 I2S implementation. Here is the example code I'm using:
SDK_2_10_1_MIMXRT1062xxxxA\boards\evkmimxrt1060\driver_examples\sai\edma_ping_pong_buffer_half_interrupt
3. I'm using the NXP SAI libraries. I inspected the PJRC implementation but it was not a good fit.

Work is being done in the following github branch. There are two commits so far. Note that the code exists in a "hack to get it working" state. The final product will be professionally crafted.
https://github.com/miketeachman/micropy ... i2s-mimxrt

Next step: map the I2S peripheral output to GPIO and check the result with an oscilloscope.

All comments and direction welcome !