Hello Guys,
Currently, I am working on secondary UART boot loader using interrupt redirection method. Secondary Bootloader will be on FLASH starting from 0x203000 . I do not find such design elegant as it introduces delays and dependency on boot loader code. NXP library does not have API for NVIC remap ( FLASH <->RAM) as it looks they are using it themselves for ROM boot loader. ( if you see datasheet they mentioned that user is not allowed to use 32 bytes at start address of RAM).
Unfortunately PN7462 is Cortex-M0, along with above restrictions, there are not many options to design secondary boot loader.
I figured out PN7462 NXP is providing USB file system based ROM boot loader and SWD based FW upload; both are not useful.
Regards,
Mayank
Hello Mayank,
Does your bootloader work? Did you write it?
I have same problem, I use the micro pn7362 (similar pn7462) to read the NFC Cards.
I started my project from the example DoorAccess, but now I also have to write the uart-bootloader, I'm not practical with NXP and the bootloaders.
You have also used a example project to write the firmware?
Can you help me? I'll be grateful.
Thanks in advance
Ivo
Hello Mayank,
first of all, unless you need to write a complex secondary bootloader as may be a CANopen bootloader, you don't need to use interrupts and I really want to discourage you to use them having written about 40-50 different primary and secondary bootloaders.
In this case you need to write your secondary bootloader using the NXP primary bootloader (so using USB) and then your PN7462 will be ready to write your application code using your secondary bootloader. So, the secondary bootloader has to be executed at every startup and has to be written at beginning of flash. If you want to see a couple of good examples of secondary bootloaders for M0 search for AN11258 and AN11257 NXP application notes, one for SPI and the other for I2C.
About the interrupt vectors relocation: the 32 ram bytes are used only by the bootloader to relocate interrupt vectors. So, in practice, if you don't need to preserve ram content in low power modes, you can use (with care) also those bytes and eventually you can use them also to relocate the secondary bootloader vectors simply because the primary bootloader already terminated its execution when the secondary bootloader starts.
About interrupt use: you need to define a simple half duplex communication protocol defining a short command set where the master can't continue to send data without receiving an ACK. Just as an example look at S19 Motorola format, define the size of your receiving buffer considering the maximum length of a S19 record and define that the slave will ack row by row when it will be ready (so the slave completed at least to convert ASCII to binary data and put them in the programming buffer). After all, you need to write sector by sector so you could use a sector buffer in RAM for that. Simple, shorter, no interrupt required and very quick.
Hi Massimo,
Thanks for reply.
I do not find any information about FLASH to RAM remap register in PN7462 datasheet.
Neither such register is available in NXP library.
do you know where to find register address of PN7462 that remap vectors to RAM?
On LPC11Xx series library it is referred as SYSMEMREMAP. I am not able to find any such reference within PN7462 specs.
Regards,
Mayank
I also didn't find SYSMEMREMAP but as I said you before you really don't need to remap any interrupt to realize a secondary bootloader. Really.
Would it be possible to get such example.
How main application can run without interrupt being remapped!!!!
Thanks
Mayank
It is possible because your bootloader has to be located at beginning of flash so it is seen as the "user application" for the primary bootloader so I confirm there is no need to relocate any interrupt. Think to write a user application: does it work? Obviously yes, so why should not work your secondary bootloader? Just to understand: is this the 1st time you write a bootloader?
Thanks Massimo,
I wrote boot loader before luckily in all those controller NVIC relocation scheme were available either via VTOR or memory relocation features.
I agree when ROM boot loader will jump to secondary boot loader the NVIC will be automatically remapped to beginning of flash (0x203000). In design, there is another application that gets executed after secondary boot loader. ( All due to NXP ROM boot loader only supports USB :smileysad: )
My application design on PN7462 is as follows.
User Flash:
0x203000 - 0x212FFF : Seconday UART based Boot loader ( Jumps to main application below )
0x213000 - Rest : Main application
So in case secondary bootloader will jump again to execute main application.
Regards,
Mayank
Hi Mayank ,
If you developed bootloader for PN7462 successfully , Can you please help me to develop a secondary boot loader ? Specially, how you relocated interrupt vectors ?
It really helps us. We see different application notes and code also but still not clear that how to relocate interrupt vector.
Thanks In advance,
Regards,
Amol
It is quite a standard scheme, you need only to define where is located your user application, so it may be located at fixed location or you can define where is located reserving 32bits in RAM to be used as a jump address. Considering to not use interrupt vectors for the secondary bootloader will simplify a lot your work and it will be much more efficient. If you try to follow my suggestion I think you will succeed quite quickly, step by step it will require not more than a couple of days.
Thanks Massimo,
I appreciate your support.
I got what you explained.
Regards,
Mayank
Hello Mayank,
Does your bootloader work? Did you write it?
I have same problem, I use the micro pn7362 (similar pn7462) to read the NFC Cards.
I started my project from the example DoorAccess, but now I also have to write the uart-bootloader, I'm not practical with NXP and the bootloaders.
You have also used a example project to write the firmware?
Can you help me? I'll be grateful.
Thanks in advance
Ivo
In PN7462 RAM area there are 2 reserved blocks on the opposite sides, the 32 bytes seems to be the same as in any NXP M0 used by IAP, the other is 256 bytes only instead then 512 bytes as in the others M0 so I suspect SYSMEMREMAP is still present as in any Cortex-M0 made by NXP but relocates 256 bytes of RAM instead of 512. SYSMEMREMAP is not standard, it is a NXP enhancement, it works more or less as in LPC2000 family because VTOR is not present in Cortex-M0. Did you check the include file for PN7462 registers? Or if in any place includes a CMSIS file for it?
have succeeded with this..?
can you share the code example which you have go it work.