Recent Posts

Pages: [1] 2 3 ... 10
1
NXPTM M522XX, KINETIS and i.MX RT / Re: Can't compile uTaskerV1.4 on Keil uVsion 5
« Last post by BangkokUni on Today at 02:31:59 PM »
Hi, Mark

Thanks a lot for your suggestion. The project is able to compiled successfully now (with target"uTaskerV1.4" as you recommend). So, I will try to flash FRDM-K64 board and see how it will go.
2
NXPTM M522XX, KINETIS and i.MX RT / Re: Can't compile uTaskerV1.4 on Keil uVsion 5
« Last post by mark on Today at 02:25:02 PM »
Hi

I believe that newer versions of the KEIL compiler have become more GCC compatible and they removed the instrinsic __wifi().

In kinetis.c change

#define __sleep_mode()        __wfi()

to

#define __sleep_mode()        __asm__("wfi")

If this also doesn't work disabled SUPPORT_LOW_POWER in config.h as the instruction is only needed when using the processor's wait mode (to save power when the core has nothing to do).

I see that you are building the target "uTaskerV1.4-BM". This target works together with the uTasker boot loader so it may be easier for you to start with the "uTaskerV1.4" target [you can select the target to be built in the IDE] instead otherwise you will need to build and install the loader before you can test some operation.

Regards

Mark
3
NXPTM M522XX, KINETIS and i.MX RT / Can't compile uTaskerV1.4 on Keil uVsion 5
« Last post by BangkokUni on Today at 12:10:34 PM »
I am just starting to use utasker for my class as supplementary tool for students. Hopefully this tool will help students to gain some more understanding about Arm programming. So, I am trying to get familiar with utasker which seems not to be an easy job. Anyway, currently I try to use Keil uVision 5 to build uTaskerV1.4 which is downloaded from https://github.com/uTasker/uTasker-Kinetis. I've followed the instruction in "Kinetis Compiler/IDE Information" page (https://www.utasker.com/kinetis/compilers.html#KEIL) and also from youtube "uTasker SHORT Getting Started - From GIT to KDS build" (https://www.youtube.com/watch?v=K8ScSgpgQ6M&t=311s). Then, when I build the project there will be an error message about ".\Objects\uTaskerV1_4_BM.axf: Error: L6218E: Undefined symbol wfi (referred from kinetis.o)." The following message is output when I build the project in Keil uVision 5:

-----------------------------
Rebuild started: Project: uTaskerV1.4
*** Using Compiler 'V6.18', folder: 'C:\Keil_v5\ARM\ARMCLANG\Bin'
Rebuild target 'uTaskerV1.4-BM'
compiling eth_drv.c...
compiling can_drv.c...
compiling SSC_drv.c...
compiling GlobalTimer.c...
compiling iic_drv.c...
compiling low_power.c...
compiling uFile.c...
compiling uNetwork.c...
compiling USB_drv.c...
compiling Tty_drv.c...
compiling uMalloc.c...
compiling Watchdog.c...
compiling dhcp.c...
compiling arp.c...
compiling uTasker.c...
compiling dns.c...
../../../uTasker/Driver.c(948): warning: implicit conversion from 'unsigned long' to 'float' changes value from 4294967295 to 4294967296 [-Wimplicit-const-int-float-conversion]
        if (floatToConvert >= (unsigned long)0xffffffff) {
                           ~~ ^~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
compiling Driver.c...
compiling Ethernet.c...
compiling ftp.c...
compiling icmp.c...
compiling http.c...
compiling ip_utils.c...
compiling ip.c...
compiling time_keeper.c...
compiling NetBIOS.c...
compiling pop3.c...
compiling snmp.c...
compiling ppp.c...
compiling smtp.c...
compiling tcp.c...
compiling telnet.c...
compiling tftp.c...
compiling udp.c...
compiling webutils.c...
compiling zero_config.c...
compiling igmp.c...
compiling ftp_client.c...
compiling application.c...
compiling KeyScan.c...
compiling debug.c...
compiling usb_application.c...
compiling modbus_app.c...
compiling snmp_mib_handlers.c...
compiling webInterface.c...
compiling NetworkIndicator.c...
compiling FreeMaster.c...
compiling nRF24201.c...
compiling MODBUS.c...
assembling kinetis_asm.s...
compiling GLCD.c...
compiling LCD.c...
compiling mass_storage.c...
compiling kinetis.c...
linking...
.\Objects\uTaskerV1_4_BM.axf: Error: L6218E: Undefined symbol wfi (referred from kinetis.o).
Not enough information to list image symbols.
Not enough information to list load addresses in the image map.
Finished: 2 information, 0 warning and 1 error messages.
".\Objects\uTaskerV1_4_BM.axf" - 1 Error(s), 1 Warning(s).
Target not created.
Build Time Elapsed:  00:00:04
-----------------------------

I use Arm compiler version 6, and already modify parameter in "Asm" Tab and "Linker" Tab in "Option for Target" of uVision's project accordingly (I use FRDM-K64F Board). It seems like the linker can't found "__wfi()" in "kinetis.co". I am not sure whether this error is from unsupport feature of ARMv7 or not (I guess). Can u suggest about how to solve this problem ?
4
NXPTM M522XX, KINETIS and i.MX RT / Re: reinstalling serial loader with fallback loader, how to start fallback loader?
« Last post by mark on April 07, 2024, 11:53:28 PM »
Hi

The fall-back loader is intended mainly as a loader to install new serial loader versions. It can be started from the application using the "fboot" command or from the serial loader using the "fb" command.
If the serial loader were corrupted (check-sum or authentication is invalid) it will behave as if it is not available and start the fall-back loader so that an un-corrupted version can be loaded.
Typically the primary loader is configured to start the fall-back loader if it has counted 16 watchdog resets:
- that means that there is a serial loader (or more likely) an application that is failing (possibly not allowing the serial loader to be commanded)
- after the failure has taken place 16x (if an application had been loaded that almost immediately hard faults due to a certain error were loaded it would watchdog reset every few seconds) the boot loader will start so that the user has the opportunity to load a new serial loader version
- the fall-back loader will typically automatically start the serial loader after 15s, thus giving the user the opportunity to load a new application
- the serial loader typically times out after 60s (when no activity is taking place) and so the cycle will repeat - the idea is that the user should not need to wait that long before the fall-back and then the serial loaders are automatically offered in such a case

Regards

Mark
5
NXPTM M522XX, KINETIS and i.MX RT / reinstalling serial loader with fallback loader, how to start fallback loader?
« Last post by jackking on April 07, 2024, 03:42:12 PM »
I am reading the test drive document for the Serial Loader: https://www.utasker.com/docs/iMX/uTaskerLoader_TestDrive.pdf

the doc mentions:
"recovery via serial “Fall-back” loader when a faulty application or a faulty serial loader is installed"

But the doc doesn't describe how this actually happens.   How does uTaskerBoot know to start the fallback loader instead of the serial loader if the serial loader is corrupted?

I see the fallback loader start if the serial loader is missing completely, but how would this work if the serial loader is present, but corrupted or needs to be updated?

thanks



6
NXPTM M522XX, KINETIS and i.MX RT / Re: Jumping to SerialLoader from flashloader (blhost)?
« Last post by jackking on April 07, 2024, 03:37:27 PM »
Thanks for the reply, I am going to continue trying to get my blhost based reset working with my existing flashloader (based on the NXP mcu-boot project).

I will update here if I have any success.

7
NXPTM M522XX, KINETIS and i.MX RT / Re: Jumping to SerialLoader from flashloader (blhost)?
« Last post by mark on April 04, 2024, 12:33:12 AM »
Hi

I don't have experience with using blhost but if the serial loader has been installed into flash I would expect that a reset would cause it to start.

I have, however, worked with the SDP protocol that blhost uses and used the following technique:

1. I build the serial loader using the bat file/make file method which generates and output using (see make_uTaskerSerialBoot_GNU_iMX):

# Create SDP output file and show its size
uTaskerSerialSDP.elf: $(OBJS) $(OBJS2_SDP) iMX_RT_10XX_SDP_BOOT.ld
   $(CC_LNK) $(C_FLAGS) -Os -g -TiMX_RT_10XX_SDP_BOOT.ld -nostartfiles -Xlinker --gc-sections -lm -Wl,-Map=uTaskerSerialSDP_BM.map -o uTaskerSerialSDP.elf $(OBJS) $(OBJS2_SDP)
   $(CC_OBJ) --only-section=.data --only-section=.init --only-section=.text --only-section=.rodata --only-section=.vectors --output-target=binary uTaskerSerialSDP.elf uTaskerSerialSDP.bin
   $(CC_SIZE) uTaskerSerialSDP.elf
   $(CC) -v

This output is suitable for use by loading with the SDP protocol (it is loaded and run in OCRAM)
I think I set this define in config.h
#define CONFIG_SDP_LOADER                                        // build the serial loader to work as a downloaded loader with the NXP serial download protocol

2. The serial loader can be build with any options and the one I use is SREC via USB-CDC

3. When this binary is installed and started (I think it is equivalent to when you load your flashloader and will be suitable for any boards that can run the serial loader since it will be configured with the same flash driver, and can be modified to add more functions such as test functions for production) it runs this serial loader and so appears as a CDC device. Like this the host can load SREC files (in order to install the final serial loader + application into flash) and can be commanded to start with the "go" command.

Regards

Mark

P.S. I use a second i.MX RT for production programming that uses the SDP protocol via USB (as host) connected to fresh i.MX RTs in their ISP mode. It detects when they enumerate, installs the uTaskerSerialSDP.bin that I generated for the target and starts it. The device then enumerates as USB-CDC and the host sends the SREC interface "bc", "ld", SREC image, "go" commands to install the complete serial loader/application.
At the same time the i.MX RT host controls the bed of nails tester to test the board and program other parts on it.
I have used the technique a number of times in quite large volumes - recently I tested/programmed 1000 boards myself and they all programmed without any glitches.
8
NXPTM M522XX, KINETIS and i.MX RT / Jumping to SerialLoader from flashloader (blhost)?
« Last post by jackking on April 03, 2024, 03:15:18 PM »
I am trying to completely automate my dev cycle, using command line sdphost to load the flashloader, then blhost to write the uTasker Serial Loader.  This is instead of using MCU Boot Utility.

I can get the SerialLoader written to flash without issues, but I would like to then cause blhost to jump to execution of the SerialLoader.

I tried following this approach: https://community.nxp.com/t5/MCUXpresso-Secure-Provisioning/BLHost-Execute-application-from-NOR/td-p/1546972

It does jump, but the SerialLoader doesn't seem to actually execute correctly, so I must be missing something.

Has anyone tried this with the uTasker SerialLoader?

Here are my commands to try and execute the jump from blhost:
Code: [Select]
../secure_provisioning/blhost -t 5242000 -u 0x15A2,0x0073 -- read-memory 0x60001000 8
Inject command 'read-memory'
Successful response to command 'read-memory'

d1 00 20 41 00 20 00 60

(1/1)100% Completed!
Successful generic response to command 'read-memory'
Response status = 0 (0x0) Success.
Response word 1 = 8 (0x8)
Read 8 of 8 bytes.

Application address:  0x60002000
../secure_provisioning/blhost -t 5242000 -u 0x15A2,0x0073 -- read-memory 0x60002000 8
Inject command 'read-memory'
Successful response to command 'read-memory'

00 c0 2b 20 61 33 00 60

(1/1)100% Completed!
Successful generic response to command 'read-memory'
Response status = 0 (0x0) Success.
Response word 1 = 8 (0x8)
Read 8 of 8 bytes.

Stack pointer:  0x202bc000
Reset vector:  0x60003361
../secure_provisioning/blhost -u 0x15A2,0x0073 -- execute 0x60003361 0 0x202bc000
Inject command 'execute'
Successful generic response to command 'execute'
Response status = 0 (0x0) Success.

9
NXPTM M522XX, KINETIS and i.MX RT / Re: Set up for ADC on i.MX RT... not getting it.
« Last post by mark on March 21, 2024, 10:41:59 PM »
The ADC interface 'attempts' to be compatible across processors and ADC types so some of the values will not do anything but can be left so that the interface remains operational with those that need them, or react to them.

The calibration flag should only be set once, the first time the interface is called (for each ADC).

The easiest way to learn the interface is to run the main application in Visual Studio and step through the code so that the effect of flags can be seen. The idea is to start with a basic interface that has a certain amount of features, and basic compatibility although the internal workings may not be highly efficient due to this. One can see which paths are used (and needed) and take these into a custom function if speed is important.

Regards

Mark
10
NXPTM M522XX, KINETIS and i.MX RT / Re: Set up for ADC on i.MX RT... not getting it.
« Last post by jackking on March 21, 2024, 09:19:42 PM »
ah, thanks!  That is working now.  I may forgo the chaining for this test, I am just trying to understand the ADC setup.
Pages: [1] 2 3 ... 10