Ok, I have the same issues with the board I designed.
So going back to the FRDM-K82F board, I have performed some more testing to determine what is happening with each added NOP.
I have looked at the boot behaviour whilst adding more NOP's into the vanilla led_demo_qspi demo included with the FSL_Kinetis_Bootloader_K80_Tools_1_0_0
The NOP's am adding are as follows:
int main(void)
{
copy_to_ram();
clock_change();
hardware_init();
milliseconds_delay_init();
__asm("nop"); //Add multiple NOP's
uint32_t led_idx = LED0;
while(1)
{
led_toggle(led_idx);
milliseconds_delay(1000);
led_toggle(led_idx);
led_idx <<= 1;
if(led_idx > MAX_LED_IDX)
{
led_idx = LED0;
}
// Re-enter bootloader if the bootloader pin is asserted.
if (is_bootloader_pin_asserted())
{
app_enter_bootloader();
}
}
}For every NOP I add, I recompile and regenerate a SB file both encrypted and plain text:
- For the non-encrypted firmware version the following commands are passed to elftosb to generate the .sb used to program the K82F:
- elftosb -V -c qspi_image.bd -o plain_image.sb
- The following files that are attached to this ticket have been used to generate the .sb file:
- plain_image.sb
- qspi_config_block_generator.c and qspi_config_block.bin
- The non-encrypted firmware version is programmed in to the K82F using the following blhost command sequence
- blhost -p COM17,115200 -- flash-erase-all-unsecure
- blhost -p COM17,115200 -- write-memory 0x20000000 qspi_config_block.bin
- blhost -p COM17,115200 -- configure-quadspi 1 0x20000000
- blhost -p COM17,115200 -- flash-erase-region 0x68000000 4096
- blhost -p COM17,115200 -- write-memory 0x68000000 qspi_config_block.bin
- blhost -p COM17,115200 -- flash-erase-region 0x0 0x800
- blhost -p COM17,115200 -- write-memory 0x40c {{FEBDFFFF}}
- blhost -p COM17,115200 -- reset
- timeout 4
- blhost -d -V -p COM17,115200 -- receive-sb-file plain_image.sb
- For the encrypted firmware version the following commands are passed to elftosb to generate the .sb used to program the K82F:
- elftosb -V -c qspi_image_encrypt.bd -k key.txt -o encrypted_image.sb
- The following files that are attached to this ticket have been used to generate the .sb file:
- encrypted_image.sb
- qspi_config_block_generator.c and qspi_config_block.bin
- key.txt
- The encrypted version also need the keys to be programmed, the following commands are passed to elftosb to generate the .sb used to program the K82F keys:
- elftosb -V -c program_keys.bd -o program_keys.sb
- The following files that are attached to this ticket have been used to generate the .sb key file:
- program_keys.bd
- The encrypted firmware version is programmed in to the K82F using the following blhost command sequence
- blhost -p COM17,115200 -- flash-erase-all-unsecure
- blhost -p COM17,115200 -- get-property 12
- blhost -p COM17,115200 -- write-memory 0x20000000 qspi_config_block.bin
- blhost -p COM17,115200 -- configure-quadspi 1 0x20000000
- blhost -p COM17,115200 -- read-memory 0x68000000 16
- blhost -p COM17,115200 -- flash-erase-region 0x68000000 4096
- blhost -p COM17,115200 -- write-memory 0x68000000 qspi_config_block.bin
- blhost -p COM17,115200 -- flash-erase-region 0x0 0x800
- blhost -p COM17,115200 -- write-memory 0x40c {{febfffff}}
- blhost -p COM17,115200 -- reset
- blhost -p COM17,115200 -- read-memory 0x68000000 512
- blhost -p COM17,115200 -- receive-sb-file program_keys.sb
- timeout 4
- blhost -d -V -p COM17,115200 -- receive-sb-file encrypted_image.sb
I am programming the K82F on the FRDM board via the J24, the BlueTooth Header. The BlueTooth header uses PTC3 and PTC4 (UART1). I have moved J23 jumper to position 2-3 so I can use SW1 to reset the processor.
The boot scenarios I have tested are as follows:
- Will the processor boot after programming the firmware?
- Will the processor boot after pressing SW1 with serial dongle connected?
- Will the processor boot after pressing SW1 without serial dongle connected?
- Will the processor boot after power cycling with serial dongle connected?
- Will the processor boot after power cycling without serial dongle connected?
Observations:
1 Will the processor boot after programming the firmware:
- Depending on the number of NOPs added to the code, either the processor would boot or not.
- Sometimes the processor would boot using the non-encrypted and would not boot using the encrypted version of firmware using the same number of NOPs.
- Sometimes the processor would not boot using the non-encrypted and would boot using the encrypted version of firmware using the same number of NOPs.
- Sometimes the processor would boot using the non-encrypted and would boot using the encrypted version of firmware using the same number of NOPs.
- Sometimes the processor would not boot using the non-encrypted and would not boot using the encrypted version of firmware using the same number of NOPs.
- If the processor did not boot, removing the serial programming cable and touching the Rx pin of UART1 would make the processor boot.
- When to processor did not boot, it was observed that the RESET Pin strobes every 2.5 seconds for 100us.
2 Will the processor boot after pressing SW1 with serial dongle connected?
- The result of this test was the same as observation 1
3 Will the processor boot after pressing SW1 without serial dongle connected?
- The result of this test was the same as observation 1
4 Will the processor boot after power cycling with serial dongle connected?
- The result of this test was the same as observation 1
5 Will the processor boot after power cycling without serial dongle connected?
- The result of this test showed that irrespective of if the firmware was encrypted or not encrypted, and irrelevant of the number of NOP's, the processor would not boot if the power was cycled with the serial dongle not connected. The processor would enter the bootloader state where by reconnecting the serial dongle, blhost can communicate with the bootloader.
A pattern has emerged based on the number of NOPs added. See the following table:
Summary
Due to the behaviour of the processor during boot and the fact that touching the Rx pin of bootloader UART1 (UART0 and UART2 do the same), I think there is possibly an issue with the K82F ROM bootloader. I think it would be useful for an NXP to look at this and try and reproduce on the same silicon version 1N03P. It is possible by touching the Rx pin I am inducing mains hum and effecting the bootloader state machine?
I have seen in the errata for the K82F processor that SPI has an issue with the bootloader, I have disabled SPI in my BCA (.enabledPeripherals = 0x1) and therefore the problem should only isolated to the UART.
The fact that when the FRDM-K82F is powered from a lab power supply (I have tried 2 different ones) and it enters the ROM bootloader when the power is turn on suggests the bootloader peripheral detect has an anomaly during power on or it's a power sequencing of the K82F and External QuadSPI flash. Perhaps the QuadSPI flash does not initilise in time for the K82F to read the BCA?
I don't think I have made a mistake in the code as the code is straight from an example provided with the FSL_Kinetis_Bootloader_K80_Tools_1_0_0, it would be very much appreciated if someone who has experience of this processor and booting from external QuadSPI flash could take a look at my project to see if I have made any obvious mistakes.
If any one has a project that they know to work using the FRDM-K82F and QuadSPI that can be built using KDS 3.2.0 that they could send to me so I can verify my hardware, that too would be much appreciated.
John
