Recent Posts

Pages: [1] 2 3 ... 10
1
NXPTM M522XX, KINETIS and i.MX RT / Re: WDOG operation
« Last post by Anton on April 12, 2019, 05:03:55 PM »
Mark, thanks a lot. #define WATCHDOG_DISABLE()    1 definitely helped.
2
NXPTM M522XX, KINETIS and i.MX RT / Re: WDOG operation
« Last post by mark on April 12, 2019, 12:50:30 PM »
Hi

The jump to the application is the same whether GO is executed or it is immediately started. What may be different is that something else was also configured (like ports) when the GO method was used. This is however unlikely to change the application's behavior.

The watchdog is always configured by the boot loader- in your case

#define ACTIVATE_WATCHDOG()    UNLOCK_WDOG(); WDOG_TOVALL = (2000/5); WDOG_TOVALH = 0; WDOG_STCTRLH = (WDOG_STCTRLH_ALLOWUPDATE | WDOG_STCTRLH_STNDBYEN | WDOG_STCTRLH_WAITEN | WDOG_STCTRLH_STOPEN | WDOG_STCTRLH_WDOGEN); // watchdog enabled to generate reset on 2s timeout (allow updates later if required)

Notice that the watchdog is set to 2s but is not locked, meaning that your application can disable it.

To disable the watchdog in the serial loader you can build it with
#define WATCHDOG_DISABLE()    1

Since I can't explain why the application resetting and also can't disable the watchdog (maybe it is not getting to the watchdog disable?) I would suggest disabling the watchdog in the debugger and setting a break-point in the application initialisation code and subsequently step what is taking place. With the watchdog disabled no WDOG reset should be possible and it may make it easier to detect something.

Good luck

regards

Mark



3
NXPTM M522XX, KINETIS and i.MX RT / WDOG operation
« Last post by Anton on April 12, 2019, 10:09:11 AM »
Mark,

I have now more or less a working bootloader + application image running on FRDM-K22F board, where application starts if SW2 is not asserted or application can be started via `go` command after entering bootloader. The thing that bothers me is that if bootloader is entered and then application is executed via `go` command everything works as expected, but if pure reset is performed and application starts directly, then a get a reset every couple of seconds due to wdog (RCM reports 0x20 as the cause of reset). WDOG->STCTRLH register after application boot-up indicates that watchdog is disabled (bit 0 is at logic zero). I've attempted to disable wdog after application start, but that does not seem to help, when jumping directly to applicaton.
4
µTasker general / Re: uTaskerSerialBoot fails on cross-compilation step
« Last post by Anton on April 10, 2019, 06:41:10 PM »
Mark, thanks a lot. Everything works as expected with the new files.
5
µTasker general / Re: uTaskerSerialBoot fails on cross-compilation step
« Last post by mark on April 08, 2019, 02:12:14 PM »
Hi Anton

It is a bit of a juggling act to remove some routines (to avoid warnings) in certain combinations but ensure that they are there in others - mainly it is the control of the define NEEDS_BLANK_CHECK in serial_loader that was not always correct.

I just tested various combinations again and hopefully have tuned them better - if you pull the serial loader project files
config.h
serial_loader.c
usb_device_loader.c

you may find that all of the combinations are then OK.

There are a few combinations that don't work - not due to the local define control not being correct but because they are not foreseen and would need code modifications rather than define control tuning. These are:
- USB-CDC together with a KBOOT on UART or KBOOT HID composite
- USB-CDC and the developer's loader on serial

In an emergency, when a local subroutine is missing (not enabled), you can edit its dependency so that it is forced on and so builds. If you tell me which combination causes it I can look into tuning further but I think with the update I just did this will not need to be done.

Good luck

Regards

Mark

P.S. I also attached the files as reference

6
µTasker general / Re: uTaskerSerialBoot fails on cross-compilation step
« Last post by Anton on April 06, 2019, 09:45:57 PM »
Mark,

Just to report back. After I've pulled down new version, the cross-compilation process works and I'm actually able to run bootloader on frdm-k22f board.
I've reviewed ?Tasker – Serial Loader User’s Guide in order to compile bootloader as specified in the in section 4, where SREC mode is enabled and menu is available via UART, but compilation fails once SERIAL_INTERFACE is uncommented with the following error:

Quote
unresolved external symbol _fnPerformBlankCheck referenced in function _fnApplication

but if SERIAL_INTERFACE and KBOOT_LOADER are uncommented, then compilation runs fine and I'm able to access target via KinetisFlashTool. What additional settings I need to adjust to get the same functionality as described in section 4?

The same applies if I attempt to enable, for instance, USB_INTERFACE and USE_USB_CDC which fails on

Quote
unresolved external symbol _fnPerformBlankCheck referenced in function _fnApplication

or USB_INTERFACE  and USB_MSD_DEVICE_LOADER

Quote
unresolved external symbol _fnAddSREC_file referenced in function _fnLoadTerminate

7
µTasker general / Re: uTaskerSerialBoot fails on cross-compilation step
« Last post by Anton on April 06, 2019, 06:41:58 PM »
Mark, thank you! I've just pulled the latest version and will try it out, thanks a lot.
8
µTasker general / Re: uTaskerSerialBoot fails on cross-compilation step
« Last post by mark on April 05, 2019, 04:27:57 AM »
Hi Anton

I have reactivated your evaluation account so that you can pull the latest version and see whether it solves the issue or not.
In case you continue having difficulties we can do a short Skype remote desktop session to see what may be the issue on your local machine.

Regards

Mark

9
µTasker general / Re: uTaskerSerialBoot fails on cross-compilation step
« Last post by Anton on April 03, 2019, 09:05:39 PM »
Mark,

I've downloaded an evaluation version from private GIT, but haven't used it untill now. Seems that the last commit was on 26th of July, last year.

I've tried to match the contents of both batch files, so they both have the same entry:

Quote
SET PATH=%PATH%;C:\nxp\MCUXpressoIDE_10.3.0_2200\ide\tools\bin
SET PATH=%PATH%;../../../Tools

But for some reason this entry into batch file does not work for uTaskerSerialBoot project.
10
µTasker general / Re: uTaskerSerialBoot fails on cross-compilation step
« Last post by mark on April 03, 2019, 05:26:47 PM »
Hi

Which version of the Kinetis project are you using? [open source on GITHUB or professional version on private GIT server?].

Check also the two .bat files in question - is it possible that you modified one of them to include the path of your local GCC tools but not the other?

Regards

Mark
Pages: [1] 2 3 ... 10