Hi,
We're using a KE1xF with ROM bootloader. Testing the Bootloader timeout we have noticed that the bootloader spends 208ms regardless of timeout value. To check this behaviour we did a simple app that at boot resets device with different bootloader timeout, and capture reset signal with oscilloscope.
In the first image the bootloader timeout is 50ms and the second is 1ms. So you can see a delay between reset of 258ms in first example, and 209ms (see cursors) With these examples, we don't understand the extra 208ms that bootloader spends doing anything.
If we want only 10 or 50 ms in bootloader, what is the solution?
Thanks for your support
Jan
.peripheralDetectionTimeoutMs = 0x0032 //50ms
and
.peripheralDetectionTimeoutMs = 0x0001 //1ms
Solved! Go to Solution.
Hi,
I've investigated this problem. It is a ROM bootloader bug. I've reported it. But there seems no way to get around.
Regards,
Jing
Hi Jing Pan,
We already know how to set the timeout on the BCA field but we don't know why the ROM Bootloader spends an extra 208ms regardless the timeout value, so that is
Actual timeout = BCA timeout + 208ms
Our question was why are 200ms added and whether there is any solution.
Thank you.
Hi,
but in my example, it hasn't this 200ms. I use oscilloscope to capture reset pin and the output pin. It seems fine. Please take a try.
Regards,
Jing
Hi Jing Pan,
I was testing it. Modifying the startup_mke18f16.c from your example code and setting our BCA configuration values:
__attribute__ ((used,section(".BootloaderConfig"))) const struct {
unsigned int d1;
unsigned int d2; // [04:07] crcStartAddress
unsigned int d3; // [08:0b] crcByteCount
unsigned int d4; // [0c:0f] crcExpectedValue
unsigned char d5; // [10:10] enabledPeripherals
unsigned char d6; // [11:11] i2cSlaveAddress
unsigned short d7; // [12:13] peripheralDetectionTimeoutMs - Timeout in milliseconds for peripheral detection before jumping to application code
unsigned short d8; // [14:15] usbVid
unsigned short d9; // [16:17] usbPid
unsigned long d10; // [18:1b] usbStringsPointer
unsigned char d11; // [1c:1c] clockFlags - High Speed and other clock options
unsigned char d12; // [1d:1d] clockDivider - One's complement of clock divider, zero divider is divide by 1
unsigned char d13; // [1e:1e] Bootflags Enable/disable communication with host
unsigned char d14; // [1f:1f] Reserved, set to 0xFF
unsigned int d15; // [20:23] A pointer to the MMCAU configuration
unsigned int d16; // [24:27]Holds a pointer value to the key blob
unsigned char d17; // [28:28] reserved
unsigned char d18; // [29:29] Canconfig1 ClkSel[1], PropSeg[3], SpeedIndex[4]
unsigned short d19; // [2a:2b] Canconfig2 Pdiv[8], Pseg1[3], Pseg2[3], rjw[2]
unsigned short d20; // [2c:2d] txId
unsigned short d21; // [2e:2f] rxId
unsigned int d22; // [30:33] A pointer to the QSPI config
} BCA_DATA = { 0x6766636b,0xFFFFFFFF,0xFFFFFFFF, 0xFFFFFFFF, 0xE8, 0xFF, 0x000A,
0xFFFF, 0xFFFF, 0xFFFFFFFF,0xFF,0xFF,0xFF, 0xFF, 0xFFFFFFFF, 0xFFFFFFFF, 0xFF, 0xFF, 0xFFFF,
0x0123, 0x0321,0xFFFFFFFF};
We guess that there is a possible issue on the enabledPeripherals field. When we set that field to 0xFF (default value) the timeout meets with set value, but when we set only the CANbus peripheral (0xE8) the timeout adds 208ms extra to the set value.
We don't know what is happening, maybe the initialisation of peripheral adds this delay... but 200ms seems too much.
It is possible to avoid that extra timeout value?
Thanks!
Hi,
Yes, it sounds strange but I also see it. When I disable LPI2C, this 200ms delay appears. It seems you have to enable LPI2C whether or not to use it.
Regards,
Jing
Hi Jing Pan,
thank you for the reply.
In our application is not possible to enable LPI2C. We can only have the CANbus peripheral enabled. We'r running on a 1.2.0 Bootloader version, is there any way to fix that problem?
Best regards,
Jan.
Hi,
I've investigated this problem. It is a ROM bootloader bug. I've reported it. But there seems no way to get around.
Regards,
Jing