RT1170 Port of MicroPython

[Thinbungee]

Does anyone have experience of using MicroPython with the RT1170 ? I am looking to evaluate it using the NXP eval board but am struggling to get started. I can transfer the .bin build to the eval board seemingly OK, but havent seen any response on the vitual COM port after reset. What COM settings are required ?

On another tack can anyone give me any tips on building the code from source using the MCUexpresso system.

[robert-hh]

Thanks for the interest. The REPL prompt comes up at the USB1 port (J20), not the J11 you use for loading the firmware. The comm setting do not matter, but you can use 115200 baud, 8 bit, 1 stop bit. For convenience, you can set J38 to the 3-4 position to have the board powered by the J20 USB.

The software is built using the MicroPython environment, not MCUexpresso. It may be possible, but will be a long and rough ride.

[robert-hh]

After loading the firmware, you have to push reset or do a power cycle.

[Thinbungee]

Thanks for your fast response Robert. I will investigate The USB1 port and also the building process using the MicroPython environment and maybe come back later with some questions.... :)

[Thinbungee]

I have the REPL prompt - many thanks. Can you recommend an IDE to run on a PC ?

[robert-hh]

I ran the MP test set for thread with the firmware and all tests passed fine. Test done both with a Teensy board and the MIMXRT1170_EVK board.

[Thinbungee]

Great, it's really good to know that the thread tests OK. I am currently trying to get a build setup working.

[Thinbungee]

Hi Robert, any ideas where an error in building the cross compiler might come from ?

cdb@DESKTOP-7A1EQBP:/micropython/mpy-cross$ make
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
CC ../py/emitnx64.c
In file included from ../py/emitnx64.c:16:
../py/emitnative.c: In function 'emit_native_binary_op':
../py/emitnative.c:2368:38: error: comparison is always true due to limited range of data type [-Werror=type-limits]
2368 | } else if (MP_BINARY_OP_LESS <= op && op <= MP_BINARY_OP_NOT_EQUAL) {
| ^
cc1: all warnings being treated as errors
-e See https://github.com/micropython/micropython/wiki/Build-Troubleshooting
make: *** [../py/mkrules.mk:83: build/py/emitnx64.o] Error 1

[robert-hh]

If the repository is recent, it may be a compiler issue. Which version of the gcc compiler do you use? I use version 11.3 or 10.3. As far as I recall, there were problems with version 11.2.

[Thinbungee]

I am running 10.3.1 The Cross-compiler should be built for the host I read. Could you let me have a copy of your py/mkenv.mk please for comparison ?

[Thinbungee]

Yes, I uploaded the latest nightly build. Great to have your advice. I will have a look at both your FTP server and an IDE and consider.

[robert-hh]

I notice the drop in performance as well, but I could not spot the reason.It must be somewhere in the build system, since the repositories are identical. At least it's good that the official builds work well.

[robert-hh]

Found it. It was in my GNUmakefile, where DEBUG=1 is set for the MIMXRT1170 port. There is a small increase since I usually have addiotional frozen bytecode added to flash, like upysh and the pye editor.

[Thinbungee]

Nice to have the mystery resolved !

[Thinbungee]

Hi Robert, I recall you were using Segger Ozone with J-Link EDU and I presume the MIMXRT1170-EVAL. Did you buy a Segger adapter to connect the JTAG ? Is yours the J-Link EDU mini ??

[Thinbungee]

Hi Robert, I have a Segger Edu Mini connected to my RT1176 Eval board OK, and can even debug the code sometimes. What doesnt seem to work yet is loading the code through the debugger. I recall you set DEBUG=1 in your GNUmakefile. Can you tell me what the purpose of that setting was ?

[robert-hh]

I use a Segger J-Link EDU, but the mini should word as well, besides the plug size. It was little bit tricky to attach. I'm not at my desk atm, but later I can send you a sample script.

[Thinbungee]

OK, that fits. Currently I'm building Micropython on Raspberry Pi ok and can run Ozone on PC ok. But it is a mess to debug because of the file references. I imagine I can build on a Linux PC virtual machine to sort this out.

[robert-hh]

If JLinkGDBServer is available for RPI, you can as well use gdb or kdbg as debugger. Less comfortable and powerful as Ozone, but it works.

[Thinbungee]

Hi Robert, I have managed to do a little development for the RT1176 with the RPi compilation and the Segger debugger. The RPi has proved unreliable however so am now trying to setup with a x86 box and Ubuntu. From what you have said this sounds similar to your build configuration. Currently the mpy-cross make will not run however, producing a "file in wrong format" error. Do you need to alter the make files in your build setup for the x86 host architecture ?

[robert-hh]

I run a x86 computer with debian Linux, and did not have to change anything at the make files. mpy-cross is a host computer application, in that case a linux app.

[Thinbungee]

Thanks as always for the fast reply. I cleared the mpy-cross error by deleting all the .o files and totally rebuilding. Ozone is working much better on the x86 box with Ubuntu so am really pleased to have a much more efficient development system. All the best, Chris

[robert-hh]

Loading the code through the debugger works here with my both the Segger EDU and the EDU mini. You may have to disconnect the debug USB port.
The option DEBUG=1 during build disables optimization. That disables inlining by the compiler. That makes it easier during debugging to single step through the code.

[Thinbungee]

One little thing I have fixed for the MIMXRT1170 EVK board is the LEDs. They now both work from MicroPython on my board. Am not sure how best for a newbie amateur to get these changes reviewed and incorporated ??

[robert-hh]

You have to create a Pull Request including only the change that you made.