This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Performing a soft reset on the Cirrus Logic EP7312
- From: "Dan Conti" <danc at fullplaymedia dot com>
- To: <ecos-discuss at sources dot redhat dot com>
- Date: Tue, 29 Jan 2002 12:22:21 -0800
- Subject: RE: [ECOS] Performing a soft reset on the Cirrus Logic EP7312
You should be able to do the following:
{
void (*f)() = 0;
f();
}
since you have already disabled the cache and turned off interrupts, you
should be fine. you might want to make sure that you call
HAL_UCACHE_INVALIDATE() _after_ calling HAL_UCACHE_DISABLE().
in the event that the above call to f() doesn't work, you could try
using:
void (*f)() = hal_vsr_table[0];
which (should) give you the appropriate reset vector.
> -----Original Message-----
> From: Chris Sekula [mailto:chriss@turnpikeglobal.com]
> Sent: Tuesday, January 29, 2002 12:17 PM
> To: ecos-discuss@sources.redhat.com
> Subject: [ECOS] Performing a soft reset on the Cirrus Logic EP7312
>
>
> I'm programming an application for the Cirrus Logic EP7312 with eCos
> 1.3.1. I'd like to provide the ability to reprogram the
> kernel/application residing in Flash by uploading a new
> application via
> the serial port or a wireless module. Once the reprogramming is
> complete, I want the application to reset itself and begin
> executing on
> its own without the need for a power on reset.
>
> I wrote the code to accept a new kernel/application from the
> serial port
> or wireless module, but it appears that I am having problems executing
> the reset command.
>
> My code accepts each byte of the new application from either
> the serial
> port or wireless module and then copies each byte to a
> defined location
> in RAM. I then copy the code for erasing sectors of the Flash and
> writing to the Flash into RAM as well. I then disable the cache, lock
> the scheduler and disable interrupts. I then execute the function for
> erasing and programming which had been copied into RAM. After
> programming the final command that I execute out of RAM is my reset
> command which is an assembly command that loads the program
> counter with
> the address of the reset vector:
>
> asm volatile ("ldr pc, =0xe0000000");
>
> where 0xe0000000 is, I presume, the reset vector for the
> EP7312 on eCos
> 1.3.1.
>
> Initially, I found that this procedure worked quite well. The
> application would accept the new code from the serial port, reprogram
> itself, perform the reset and start up again. However, recently I have
> been noticing that the application has been hanging after
> reprogramming.
> I've checked the Flash with a debugger to verify that the
> kernel/application had been reprogrammed correctly. It appears that my
> reset command may be incorrect.
>
> I performed an additional test to exercise the reset command. The
> following code should toggle an LED on and off 5 times and then issue
> the reset command. To check if the reset command executes, I issue a
> command following the reset to turn on a Flasher. If the reset command
> does not execute, I should see the Flasher begin blinking
> following the
> 5 toggles of the LED.
>
> #define STACKSIZE 5000
> static char stack[STACKSIZE];
> static cyg_handle_t hmainThread;
> static cyg_thread mainThread_obj;
> static void MainProc(CYG_ADDRESS data);
>
> extern "C" void cyg_user_start(void)
> {
> cyg_thread_create(4, MainProc, (cyg_addrword_t)0, "mainproc",
> (void*)&stack, STACKSIZE, &hmainThread,
> &mainThread_obj);
> cyg_thread_resume(hmainThread);
> }
>
> static void MainProc(CYG_ADDRESS data)
> {
> HAL_IO_REGISTER PortDOut = 0x80000003;
> HAL_IO_REGISTER Flasher = 0x800022c0;
> for (int x=0; x<5; x++)
> {
> HAL_WRITE_UINT8(PortDOut, 0x06); // LED ON
> cyg_thread_delay(50);
> HAL_WRITE_UINT8(PortDOut, 0x04); // LED OFF
> cyg_thread_delay(50);
> }
>
> asm volatile ("ldr pc, =0xe0000000");
>
> // flash every 1 sec, 50% duty cycle (eg. .5 secs on, .5 secs off)
> HAL_WRITE_UINT8(Flasher, 0x60);
>
> }
>
> The first LED toggled 5 times and then remained off. The
> Flasher did not
> begin blinking. This indicates to me that the reset command executes,
> but the kernel hangs somewhere after restarting.
>
> Can anyone offer any suggestions as to how to perform a
> 'software reset'
> correctly or how to possibly correct what I am already doing?
>
> Any comments would be greatly appreciated.
>
> Regards,
>
> CHRIS.
>
>
>
>
>
>
>
>