Hardware reset

The chip can remember state after a reset - the RAM isn't automatically cleared.

So you can store a magic signature in RAM somewhere. Or you can connect an EEPROM or F-RAM memory for telling current/next binary to run.

You can obviously not just reprogram the flash with new binaries. But you can store more than one application and have a boot loader decide which application to start.

So you would first have to learn how to implement a boot loader. Come back when you have managed that, and it will be meaningful to discuss the concept of selecting which application to start. A boot loader can even do a full fallback waiting for a new binary on a serial port or downloading an application from a SPI-connected flash memory. Lots can be done. But first you need a working concept with a boot loader and with applications linked for use at an address different from the address range where the boot loader is stored.

Note that you can't catch the reset - it really do force a reset of the processor. So you have to make your decission after the processor have restarted. So whatever you do, you can't have any for loop that alternates between two applications.

The chip can remember state after a reset - the RAM isn't automatically cleared.

So you can store a magic signature in RAM somewhere. Or you can connect an EEPROM or F-RAM memory for telling current/next binary to run.

You can obviously not just reprogram the flash with new binaries. But you can store more than one application and have a boot loader decide which application to start.

So you would first have to learn how to implement a boot loader. Come back when you have managed that, and it will be meaningful to discuss the concept of selecting which application to start. A boot loader can even do a full fallback waiting for a new binary on a serial port or downloading an application from a SPI-connected flash memory. Lots can be done. But first you need a working concept with a boot loader and with applications linked for use at an address different from the address range where the boot loader is stored.

Note that you can't catch the reset - it really do force a reset of the processor. So you have to make your decission after the processor have restarted. So whatever you do, you can't have any for loop that alternates between two applications.

Hello,

Do you perhaps know how to change overwrite the date stamp of the bin file, My idea is to have two bin files on the flash memory and to change the date stamp of the first bin file so it is now older than the second and then force a reset on the micro control causing the second bin file to now be loaded into the flash memory because it has the newer time date stamp.

If you can please help me figure out how to overwrite the date stamp this would be really helpful.

How could anyone but you possibly know whether there's any kind of time stamp in your binary files, much less how to change it?

Why subvert the date stamp?

Why not just have a specific field to define which "file" to use?

Did you plan to have file data in an external flash file system, and have the boot loader reprogram the internal flash?

A common setup is to store two applications at the same time in the internal flash - the boot loader just selects which of them to start. But the boot loader don't do any reporgramming of any application when restarting.

Not sure why you think you need any file date.

the magic chip I have is set up to load the .bin file with the newest date into the flash memory so if I have two bin files, one 1997 the other 2012 the 2012 will get loaded into flash, but if I can change the 1997 to say 2013 then that .bin will get loaded into flash.

If I can add something in my code to change the date stamp and then a cfg file to handle the switching of the .bin

I am student with no money so the boot loader method is not a option at the moment. Is it possible to rename the files somehow so the extension is not .bin to say .old then perhaps the second .bin file will get loader into flash.

if (lastStatus == 1) {
write 0 into a new lastStatus.cfg
} else {
write 1 into a new lastStatus.cfg
}

if (laststatus == 1) {
rename binfile1 to .old;
rename binfile2 to .bin;
}

if (laststatus == 0) {
rename binfile1 to .bin;
rename binfile2 to .old;
}

A boot loader is not a monetary cost - it's an investment in time.

But then again - you are obviously not telling us the complete story here. Without a boot loader - what software is looking at time stamps for programming your flash? And exactly where are these binaries stored since you need to reprogram them into flash to be able to run them?

It is a magic chip that looks for the time stamps which I don't have access at the moment to the code, they are store on the flash memory but not programed into it yet.

If my code is like this for rename

62
63          /* Function rename
64           *  Rename a file in the filesystem.
65           *
66           * Variables
67           *  oldname - the name of the file to rename.
68           *  newname - the name to rename it to.
69           *  returns - 0 on success, -1 on failure
virtual int rename(const char *oldname, const char *newname) { return -1; };

How do I rename files in ARM style

I have tried

rename *out.txt AS *yes.txt;

but it does not work

There are no "ARM style" file rename.

And what is "magic" here?

If someone have given you a board with a standard LPC17xx processor but with a custom software that have some magic logic in it, you will obviously have to ask that person what magic there is - the documentation for the preprogrammed software.

I do know how to use the software Flash Magic to download software to a LPC17xx chip. But that doesn't involve playing with any time stamps on any binary files stored in any flash somewhere.

Is it possible for me to add my own code into lpc17xx

how would I add stat -c to read the time stamp and touch -d to change the time stamp much like it is in linux does any arm exist??

virtual int stat(const char *-c) { return -1; };
virtual int touch(const char *-d) { return -1; };

#!/bin/bash
#
BASE_OLD=/mnt/old-raid
BASE_NEW=/mnt/new-raid

cd $BASE_OLD
find . -type f |
while read fname
do
$BASE_NEW/${fname}

TS=$(stat -c '%Y' "${BASE_OLD}/${fname}")


TIMESTAMP=$(date -d @${TS} +'%d %b %Y %R')

touch -d "${TIMESTAMP}" "${BASE_NEW}/${fname}"

echo "${BASE_NEW}/${fname}"

done

Does anybody here understand what the OP wants from our lives?
Brother, it is not a PC your working with, OK?

Why don't you just tell me the ARM code for getting the time stamp and changing it then, because I know it exist.

The "ARM code" will require you to address the chip's RTC (I think it has one) or a network source, hardware timer etc.

And I can use that to change the .bin time stamp or do I need to change the lpc17xx time stamp so it is newer date than the .bin . if you understand what I mean instead of changing the .bin time stamp are you saying to just change the lpc17xx chips time stamp.

If your program contains the ANSI C macros __TIME__ and/or __DATA__ you can expect a "time stamp" in your .bin files regardless of LPC1768 RTC settings.
You really need to first _understand_ what you are doing (and talking about) and to my understanding you don't. Merging bin files? Are you sure that's a good idea?

I am student with no money so the boot loader method is not a option at the moment.

How exactly is a bootloader related to you not having any money?