topic Re: MPC5777C bootloader Problem in MPC5xxx

MPC5777C bootloader Problem

lukezhang — Tue, 13 Aug 2019 08:03:25 GMT

Hi all,

I have a question regarding to the implementation of mpc5777c bootloader. I followed AN5319 application note as a guideline to implement it, and now the earsing functionality works after I put certain code (like Flash_erase(), interrupt vector table and exception table) to RAM (otherwise it will issue IVOR1 fault). So here's the thing that I don't understand, I put some routines to RAM instead of flash, but as fat as I know, RAM can only store data temporary, and it cannot retain the data, which means if I power it off, and power on again, the data stored in RAM should disappear, but actually it is not, and the routines, interrupt vector all works as usual. But I only put those routines in RAM based on this question HOWTO: Run a routine from RAM in S32 Design Studio . So why does those routines put at RAM still working after a full power cycle?

Thanks

Luke

Re: MPC5777C bootloader Problem

lukaszadrapa — Tue, 13 Aug 2019 10:04:53 GMT

Hi Luke,

I wrote in the AN5319:

So, if you use initialized variables (not constants as mentioned above) for C-arrays, it's automatically copied from flash to RAM by startup code.

And in the mentioned HOWTO document, the code is manually copied from flash to RAM memory using memcpy function - you can see that in the main function.

In other words, the code is sitting in the flash memory and then it is copied to RAM after each reset.

Regards,

Lukas

Re: MPC5777C bootloader Problem

lukezhang — Wed, 14 Aug 2019 06:30:16 GMT

I see. Thanks for the explain.

Another question I faced now is, the S32 design studio generate Srecord with S2 (The address field is intrepreted as a 3-byte address), and I tried to use SRECCONV_v2.exe to convert to a 64-bit align as you mention on the document. But the output file only contains one line of S record, S7050000008C6E, and that's all of the file. I googled it and I found there is someone with similar problem with me https://community.nxp.com/thread/457300 , but no one answer. Could you help me with that?

Thanks.

Re: MPC5777C bootloader Problem

lukaszadrapa — Wed, 14 Aug 2019 11:09:50 GMT

Hi,

SRECCONV supports S3 records only. To force the S32 Design Studio to generate S3 record, use this setting (highlighted):

Regards,

Lukas

Re: MPC5777C bootloader Problem

lukezhang — Fri, 23 Aug 2019 00:49:05 GMT

Hi lukaszadrapa,

Just a following question, the bootloader now is working. But everytime it takes around 15 minutes to flash a whole Srecord file to processor. I'm thinking about speed it up, and I'm considering if there is anyway I can flash .bin file instead of .srec file since bin file has a relative smaller size. Is there any document or guideline can achieve it? Or is there any other way to speed it up?

Regards,

Luke

Re: MPC5777C bootloader Problem

lukaszadrapa — Fri, 23 Aug 2019 11:02:44 GMT

Hi Luke,

let's do some calculation. I hope I won't make a mistake:

There's 8MB flash -> 8 388 608 bytes to program.

Considering typical timing:

... programming itself will take (without SW overhead):

- using 64bits programming: 45s

- using 256bits programming:19s

- using 1024bits programming:17s

Data payload of one s-record line is 16bytes (considering output from SRECCONV). Size of whole line is 23bytes. Due to ascii format, 46 characters need to be sent per line.

To cover whole 8MB flash, we need 524 288 s-record lines. That means we need to transfer 24 117 248 characters.

When using speed 115 200 bits/s, we need 86.8us to transfer 1 ascii character (start bit + 8bit data + stop bit). To transfer whole s-record file, we need 2 093s = 34min.

Comparing to binary file:

We have 8 388 608 bytes and speed 86.8us per byte => 728s = 12min

So, optimalization of programming procedure is not so significant (but can help too) but using of binary file can decrease the transferring time to about 1/3.

But it also depends on your image - if there are large gaps in the s-record format, the difference may not be so significant because the gaps need to be transferred too in the binary image.

Transferring of binary image is much simpler than decoding of s-record lines, so it shouldn't be difficult to update the bootloader.

Regards,

Lukas