Recent Posts

Pages: 1 ... 7 8 [9] 10
81
µTasker general / Re: How to identify code that causes a SW watchdog reset
« Last post by mark on April 29, 2023, 01:45:48 PM »
Hi

If you have code that may take a long time and causes a SW WDOG timeout (but not due to an error, as such) you can increase the watchdog value in (for example the i.MX RT project)

#define ACTIVATE_WATCHDOG()     UNLOCK_WDOG3(); WDOG3_TOVAL = (2 * 32000); WDOG3_WIN = 0; WDOG3_CS = (WDOG_CS_CLK_LPO | WDOG_CS_FLG | WDOG_CS_CMD32EN | WDOG_CS_EN); // enable watchdog with 2s timeout (32kHz reference)

or add re-triggers in the code [fnRetriggerWatchdog()].

To identify the location you can add a HW timer (single-shot that can be re-triggered) configured to a slightly lower timeout than the watchdog timeout.
Add a re-trigger of it to the macro
Code: [Select]
TOGGLE_WATCHDOG_LED()
and set a break point in its interrupt handler.

If this interrupt fires you can look to see which code is executing (step out of the interrupt or look at the call stack).

Regards

Mark
82
µTasker general / How to identify code that causes a SW watchdog reset
« Last post by FAQ on April 29, 2023, 01:43:19 PM »
If I have a project that sometimes causes a SW watchdog reset - but not due to a fault such as a hard fault - how can I catch the cause if the watchdog time itself doesn't support an interrupt?
83
NXPTM M522XX, KINETIS and i.MX RT / Re: i.MX RT Linker Script files for compatibility with MCUXpresso V11.5 and above
« Last post by mark on April 24, 2023, 09:36:28 AM »
Hi Ray

I don't think there is anything in the newer GCC versions that are greatly beneficial and older ones work fine:
Maybe there are some better warning messages in newer ones (pointing out potential code issues) but these are not critical.

Regards

Mark
84
NXPTM M522XX, KINETIS and i.MX RT / Re: i.MX RT Linker Script files for compatibility with MCUXpresso V11.5 and above
« Last post by Ray on April 24, 2023, 03:41:23 AM »
I'm using Visual Studio, but have a  complete c:\gnu\ folder where I keep all my gcc stuff together.  Currently running 9-2019-q4-major-win32.  Does this MCUXpresso update use a later gcc tool chain?  I see from the source (https://developer.arm.com/downloads/-/gnu-rm)   I see a 10-2020-q4-major-win32, and the current 10.3-2021.10-win32.   Is there a prefered tool chain that is best for iMX_RT's  and Kinetis  with uTasker?   
Ray
85
NXPTM M522XX, KINETIS and i.MX RT / i.MX RT Linker Script files for compatibility with MCUXpresso V11.5 and above
« Last post by mark on April 19, 2023, 01:32:37 PM »
Hi All

With the release of NXP's MCUXpresso V11.5, which is supplied with a newer version of the GCC tool chain, i.MX RT projects could no longer be build due to an incompatibility in the linker scripts.
Interestingly this however didn't affect Kinetis projects, where the same incompatibility was not experienced.

Originally attempts were made to identify what had changed and work around it but this proved to be a dead-end and so finally a new linker script was generated using the NXP SDK and then adapted to suit the uTasker code (such as inserting the same variable section references so that the initialisation code didn't need to be modified).

The result is that by swapping out original linker scripts against newer ones projects can be built with MCUXpresso versions pre-V11.5 and post.

At this time there are still some linker scripts to be adapted and tested but for the main usage I have attached the ones that can already be used (later they will be checked into the repository for general use)

- iMX_RT_10XX_FlexSPI_NOR.ld   This can be saved to \Applications\uTaskerBoot\GNU_iMX (overwriting the original) and allows the primary loader to be built for i.MX RT 10xx parts (excluding the i.MX RT 1064)

- iMX_RT_1064_FlexSPI_NOR.ld. This can be saved to \Applications\uTaskerBoot\GNU_iMX (overwriting the original) and allows the primary loader to be built for  the i.MX RT 1064

- iMX_RT_10XX_FlexSPI_NOR_BOOT.ld. This can be saved to \Applications\uTaskerSerialBoot\GNU_iMX (overwriting the original) and also to \Applications\uTaskerV1.4\GNU_iMX and allows the secondary loaders and application to be built for i.MX RT 10xx parts operating in RAM (the main operation configuration and always used by the serial loaders).

- iMX_RT_10XX_SDP_Boot.ld. This can be saved to \Applications\uTaskerSerialBoot\GNU_iMX (overwriting the original) and allows serial download protocol images for i.MX RT 10xx parts. This tends to be built in parallel with the serial loader and so, even if the SDP outputs are never used, it will stop the build failing.

Regards

Mark
86
NXPTM M522XX, KINETIS and i.MX RT / Re: i.MX RT 1062 Stock available to uTasker users
« Last post by mark on March 11, 2023, 10:41:32 PM »
Hi

The 0.65mm pitch part is designed/intended for 4 layer boards and the NXP EVKs are 4-layer designs allowing all pins to be used and also (according to them) passes FCC tests.

The only drawback is that some room around the device is needed for fan-out of the signal lines when many are used and when some GPIOs are not needed that means that it can be packed tighter together. See the attached screen shot of the chip on the NXP layout.  6-layer board would probably alleviate this.

NXP also has a detailed design guide at https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i-mx-rt-crossover-mcus/i-mx-rt1050-crossover-mcu-with-arm-cortex-m7-core:i.MX-RT1050 "i.MX RT Hardware Development Guide for the MIMXRT1050/MIMXRT1060 Processor" - requires a log-in.

It is undeniable that more board layers and working with finer pitches and smaller holes will increase the price of a PCB and it is up to the designer to decide on such tradeoffs. However, in comparison to a K66, which - if it can be found and purchased at its normal price - tends to be much more expensive than an i.MX RT 10xx - maybe in the order of $10..15 and, coupled with much more peripherals and performance even paying more for a PCB should result in a cheaper (and potentially) better product.

I have also attached a screen shot of one of my designs where I use 77 ports/GPIO plus 1 x USB.

Regards

Mark

87
NXPTM M522XX, KINETIS and i.MX RT / Re: i.MX RT 1062 Stock available to uTasker users
« Last post by LuisHS on March 11, 2023, 12:54:57 PM »

Hi

In order to route all the ports of this microcontroller with pitch 0.65mm, is a 4-layer PCB enough or may more layers be needed?

So far I have only used 1mm pitch BGA microcontrollers with the Kinetis MK66, and 0.8mm pitch with the RT1064. With the RT1064 it's already costing me enough to be able to route a good number of ports for a project, and that with a pitch of 0.8mm, and 4 PCB layers.

Working with PCBs with 6 layers or more, and with such small vias for that 0.65mm pitch can already make the PCB quite expensive.

88
NXPTM M522XX, KINETIS and i.MX RT / Re: RT1064, boot from SD.
« Last post by mark on March 08, 2023, 06:31:48 PM »
Hi

If there were no QSPI flash the only loader available is the ROM loader, which can boot from SD cards but is not necessarily a very good choice since SD cards are unreliable in comparison to QSPI flash and if the card fails, is corrupted or is removed the board can't do anything.

It is possible for the uTasker boot loader to also load directly from SD card to RAM or SDRAM but, due to the above, I would never recommend it for an embedded system - plus why use an expensive (heat sensitive) SD card to hold a small program when a cheap ($0.50) QSPI flash can do it better? [Since a 1064 has this inside anyway it would make even less sense]

I don't know why there is a limit in ITC size in the article but that may be the ROM loader's limitation (unless eFUSEs are set possibly to change the configuration, which cannot be changed back again...!). The uTasker loader (running in the first blocks of QSPI flash) is limited to the chip's 512k ITC (since it can dynamically configure this according to the code's requirement) or much larger in SDRAM (or much larger in QSPI flash).

As noted in the article it is cool to boot from an SD card directly (without any need for QSPI flash) but whether it makes real sense in a real -world embedded system is highly unlikely.

Regards

Mark

89
NXPTM M522XX, KINETIS and i.MX RT / Re: RT1064, boot from SD.
« Last post by LuisHS on March 08, 2023, 05:36:56 PM »

Thanks Mark
And wouldn't it be possible to always boot from SD, without having to copy to flash?

I saw this article from McuonEclipse where they explain how to boot an application from SD, the processor starts the ROM bootloader, then loads the image from the SD card into RAM (ITC) and then runs it. In that configuration no internal or external FLASH memory would be needed.

https://mcuoneclipse.com/2019/01/22/tutorial-booting-the-nxp-i-mx-rt-from-micro-sd-card/

They also explain that the application is copied from SD to ITC RAM from where it runs, but that this limits the program to a maximum of 64k, which seems very little to me.

In your answer you tell me that in ITC+DTC the size of the program would be 512K, that is much more than the 64k indicated in mcuoneclipse. So this leaves me confused.

To always boot from SD, without copying to Flash, would it always be done using the Rom bootloader that would copy to ITC from where the program would run, and what would be the maximum size of the program that could be run?

Regards
90
NXPTM M522XX, KINETIS and i.MX RT / Re: RT1064, boot from SD.
« Last post by mark on March 08, 2023, 02:04:31 PM »
Hi

The standard SD card boot loader method is to have he new image on the card and load it to QSPI flash (and delete the SD card image after successful transfer).
At each subsequent boot there are three possibilities:
- copy the code from encrypted QSPI flash to ITC RAM and run it there (fastest operation)
- copy the code from encrypted QSPI flash to SRAM and run it there (second fastest operation but operation s no longer encrypted since the SDRAM operation can be observed)
- Run the code in place in QSPI Flash (XiP) or XiP-BEE (on the fly decryption). XiP is (depending on caching) up to 20x slower that running from ITC and less deterministic since the speed depends on caching so can change) -  XiP BEE is a bit slower again (about 30% I have heard). When the QSPI Flash in internal to the chip (RT1064) it is protected and possibly there is no advantage of using XiP BEE for code protection.

ITC + DTC is limited to the FlexRAM size of the chip. RT105x/6x have 512k so programs up to about 512k would be possible (as long as data is located in SDRAM or 512k OTCRAM2 (in 106x)

Large QSPI Flash are available so program size shouldn't generally be an issue (except for RT1064 where it is fixed at 4MBytes) and SDRAM loses code protection so is not always the best choice.

Regards

Mark
Pages: 1 ... 7 8 [9] 10