[ECOS] Performing a soft reset on the Cirrus Logic EP7312

Dan Conti danc@fullplaymedia.com
Tue Jan 29 12:22:00 GMT 2002

You should be able to do the following:

  void (*f)() = 0;

since you have already disabled the cache and turned off interrupts, you
should be fine. you might want to make sure that you call

in the event that the above call to f() doesn't work, you could try

  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,

More information about the Ecos-discuss mailing list