We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi All, I have bunch of code that we want to put the compiled file in the external flash, in the runtime i want to copy the code to RAM and run it from RAM. Consider that the code is using some variable in the RAM. the code is like this:
extern PROTOCOL_SOLVER PROTOCOL_CAN_SOLVER; //for ccn!!! CAN_FILTERING_ARRAY filter_array = { {0x650},1}; Can_Device m_canDev = {0x750, 0x0, 0xff, 500, &filter_array}; ProtocolProfiler profile1 = { PROTOCOL_CAN, &m_canDev, &PROTOCOL_CAN_SOLVER }; //task development ::::: ProtocolProfiler * m_CurrentProfile = &profile1; float Calculate_Ids_B0(void) { return 0.0f; } taskDiag task_sample[2] = {{1, 3, Calculate_Ids_B0, {{0, {0x10,0x90},2}}, {1}, 0, {""}, {0}}, {1, 3, Calculate_Ids_B0, {{0, {0x10,0x90},2}}, {1}, 0, {""}, {0}}}; ////just for references..... typedef struct _can_devices_ { uint16_t ID_part; uint8_t split_part; uint8_t fill_the_Rest ; uint16_t Delay_BetweenFrm; CAN_FILTERING_ARRAY * filter_array; } Can_Device; typedef struct _frame_bank_ { uint8_t frmBank[270]; uint16_t rec_byte_number; } m_FrmBank; typedef struct _PROTOCOL_SOLVER_ { uint8_t (*ConnectProcedure) (Can_Device * canSpec); uint8_t (*SendAndRecieveFrame) (Can_Device * DevSpec, uint8_t * buffer, uint16_t size_of_buffer, uint8_t bank_frm_num); } PROTOCOL_SOLVER; typedef struct _comm_protocol_profile_ { uint8_t protocol_type; Can_Device * can_spect; PROTOCOL_SOLVER * protocol_solver; } ProtocolProfiler;
I am using LPC1788 and EA-1788 board. I hope someone can help me.
Best Regards, MJM
Have your start up code in your normal internal FLASH, create a Load Region in the Scatter File describing the external FLASH, and put the RAM based code INSIDE that region.
For an example take a look at a normal scatter file, which describes internal FLASH, and your variables it is going to move into internal SRAM when it starts. The code that does this is in __main
Thanks for your replies. But you know it is a small part of code that should change dynamically. I think if I can put the code at specific address for example section 27 of ARM flash. I can replace this section at runtime from external flash.
I think it can be done easily. But I should work hard.
Thank you so much.
Don't bet too high on that project.
You must make sure that the linker knows all symbols in the fixed region really have the same fixed address for every rebuild.
While you must also make sure that any symbols the fixed part needs to access in your replaceable part have fixed addresses.
And remember that the compiler will not just play with variable and function names you include in your program. The generated code will also contain calls to helper functions in the runtime library.
Best is if you link the two parts as totally separate applications, and set up an access table for making calls to functions within the replaceable applet.
Or write the replaceable part in assembler.
Or go all-out and select a RaspPi or similar where you get real applications complete with dynamic libraries.
You know I am testing a simple procedure to handle this : each dynamic block of the code is placed at the given address. for example I have five code which they should be replaced dynamically. I compile and link them separately with the fixed part of code. In this way,I can just get and replace that section in demand. I hope this can be done easily. This is a way which I hope work!!!
Doesn't seem meaningful. Did you select a too small processor? Because if you are going to reprogram the chip, then why not do what "everyone else" is doing - have a small boot loader and then replace the full application? It is way more flexible to be able to replace 95% of the code, than to be able to replace 5%.
The speed is really important. the second part is just containing some data and some functions. these two parts are really separated. Just importing some structures and calculating some parameters. because there are about more than 1000 of these configurations.
replacing all code is done for upgrading issue by a boot-loader. But replacing the whole code is really time-consuming.
our IC is LPC1788 with external NAND flash.
"because there are about more than 1000 of these configurations."
You should try to separate code and data.
I compile and link them separately with the fixed part of code.
The phrase "the fixed part of code" means two different things, and that difference will quite likely break that plan.
Your plan appears to be based on fixing a part of the source code, which you then expect to yield a fixed part of the executable code. Well, sorry, but it ain't that simple. For that plan to ever work, you'll most likely have to tie the compiler's hands so thoroughly, disabling most meaningful optimizations, that in the end the fixed portion no longer fits into its allotted space any more.
And even if that doesn't kill your plan, there's another, equally bad issue: linking 1000 versions of the complete program will take an inacceptably long time. And you'll have to re-do it all every time you make any change to the "fixed" part of the program. I.e. the non-fixed fragments stand virtually no chance of surviving any update to the parent executble.
Thank you for your nice clarification.
I think because two parts have no overlap just like a library. I can tie the compiler hands. I hope. About the update, I think that 1000* ~3k = 3MByte. It can be manageable to update. About the compile: if the fixed part change, I should recompile them every time.you are right it is time-consuming. But It will be done automatically. By the way, I really agree with you that this solution is not neat. I should change it.
So ,as Dear Per Westermark, I should divide PROGRAM to CODE and DATA region. But how can I put the CODE in the external NAND flash? Another most important thing, I should put the encrypted ( I usually use AES 256-bit) DATA or CODE in NAND flash. Because these data are valuable in some way.
It is something hard to handle this project. But I should find a neat solution. :D:D:D
Finally, thank you so much for your valuable help and supports.