[ECOS] Changing flash wait state on SAM7

[ECOS] Changing flash wait state on SAM7

[Davies, Greg]

I've been having some strange memory issues that I've been talking about
in the "eCos causing something.. Maybe?" thread. Basically I was seeing
random values when I did a dump of any section of memory. The BDI folks
suggested I change the flash wait state. I did this and the problem went
away. 

I now have an issue similar to this while trying to debug. I can see
that the first 3 instructions set the flash wait state to 1 (by writing
0x100 to 0xffffff60), but I need it to be 3. This seems to be in a
function called reset_vector (or at least that's what gdb calls it). I
tried changing what looked like the same code (but called
__flash_init__) in
packages\hal\arm\at91\at91sam7s\current\include\hal_platform_setup.h,
and I rebuilt everything, but when I loaded on the new code, it still
wrote the same value. Am I changing the flash wait state in the right
spot?

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Changing flash wait state on SAM7

[Andrew Lunn]

On Mon, Apr 07, 2008 at 01:34:58PM -0300, Davies, Greg wrote:
> I've been having some strange memory issues that I've been talking about
> in the "eCos causing something.. Maybe?" thread. Basically I was seeing
> random values when I did a dump of any section of memory. The BDI folks
> suggested I change the flash wait state. I did this and the problem went
> away. 
> 
> I now have an issue similar to this while trying to debug. I can see
> that the first 3 instructions set the flash wait state to 1 (by writing
> 0x100 to 0xffffff60), but I need it to be 3. This seems to be in a
> function called reset_vector (or at least that's what gdb calls it). I
> tried changing what looked like the same code (but called
> __flash_init__) in
> packages\hal\arm\at91\at91sam7s\current\include\hal_platform_setup.h,
> and I rebuilt everything, but when I loaded on the new code, it still
> wrote the same value. Am I changing the flash wait state in the right
> spot?

Yes, but the dependencies don't always work for this. Delete
install/lib/vectors.o and recompile.

What how fast are you clocking your device? 

// Macro to initialise the Memory Controller
        .macro _flash_init
__flash_init__:
#if CYGNUM_HAL_ARM_AT91_CLOCK_SPEED > 30000000
        // When the clock is running faster than 30MHz we need a wait state
        ldr     r0,=AT91_MC
        ldr     r1,=(AT91_MC_FMR_1FWS)
        str     r1,[r0,#AT91_MC_FMR]
#endif
#if CYGNUM_HAL_ARM_AT91_CLOCK_SPEED > 60000000
        ldr     r1,=(AT91_MC_FMR_2FWS)
        str     r1,[r0,#AT91_MC_FMR]
#endif
        .endm


       Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Changing flash wait state on SAM7

[Andrew Lunn]

On Mon, Apr 07, 2008 at 01:34:58PM -0300, Davies, Greg wrote:
> I've been having some strange memory issues that I've been talking about
> in the "eCos causing something.. Maybe?" thread. Basically I was seeing
> random values when I did a dump of any section of memory. The BDI folks
> suggested I change the flash wait state. I did this and the problem went
> away. 

Something else to check. I found that my JTAG device will download a
little bit of code which starts the PLL running and then swaps from
slow clock to pll clock. This allows it to download code faster etc.
It could be that it is setting a really fast clock which does require
more wait states. So when you start eCos using BDI it is running on a
fast PLL clock, not slow clock, or a medium speed PLL. The first thing
the startup code does is reprogram the wait states, which could get it
into trouble.

See if you have any configuration options for BDI. Another option
would be to change hal_platform_setup to only change the wait states
once the CPU is running on slow clock.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Changing flash wait state on SAM7

[Tom Deconinck]

On Mon, Apr 7, 2008 at 7:17 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, Apr 07, 2008 at 01:34:58PM -0300, Davies, Greg wrote:
>
> > I've been having some strange memory issues that I've been talking about
>  > in the "eCos causing something.. Maybe?" thread. Basically I was seeing
>  > random values when I did a dump of any section of memory. The BDI folks
>  > suggested I change the flash wait state. I did this and the problem went
>  > away.
>
>  Something else to check. I found that my JTAG device will download a
>  little bit of code which starts the PLL running and then swaps from
>  slow clock to pll clock. This allows it to download code faster etc.
>  It could be that it is setting a really fast clock which does require
>  more wait states. So when you start eCos using BDI it is running on a
>  fast PLL clock, not slow clock, or a medium speed PLL. The first thing
>  the startup code does is reprogram the wait states, which could get it
>  into trouble.
>
>  See if you have any configuration options for BDI. Another option
>  would be to change hal_platform_setup to only change the wait states
>  once the CPU is running on slow clock.
>
>      Andrew
>
>
>
>  --
>  Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>  and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>
The trick I did was to disable most startup macro's in the platform
setup code and let my BDI probe do most of the configuring. My
experience with clocks getting reconfigured at eCos startup wasn't a
very good one ;)

Tom

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Changing flash wait state on SAM7

[Andrew Lunn]

> The trick I did was to disable most startup macro's in the platform
> setup code and let my BDI probe do most of the configuring. My
> experience with clocks getting reconfigured at eCos startup wasn't a
> very good one ;)

What happens when you don't have a BDI connected? 

Do you know what the BDI actually does which causes problems? It would
be good to tweak eCos a little to make BDI work properly. However, i
don't have access to a BDI and i have no problems with my JTAG base
debugger....

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Changing flash wait state on SAM7

[Jürgen Lambrecht]

[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]

Andrew Lunn wrote:

>>The trick I did was to disable most startup macro's in the platform
>>setup code and let my BDI probe do most of the configuring. My
>>experience with clocks getting reconfigured at eCos startup wasn't a
>>very good one ;)
>>    
>>
>
>What happens when you don't have a BDI connected? 
>
>Do you know what the BDI actually does which causes problems? It would
>be good to tweak eCos a little to make BDI work properly. However, i
>don't have access to a BDI and i have no problems with my JTAG base
>debugger....
>
>        Andrew
>
>  
>
My procedure (set-up by company Mind) to debug with a JTAG debugger as 
the BDI (I use a BDI2000 from Abatron - I don't know if there are other 
ones) or the PEEDI (Ronetix) is to use an eCos RAM build.
Then BDI needs a startup config file (configured with the config command 
in a bdi telnet session), and with that file the BDI initializes the 
processor (the clock and the chip selects, maybe some GPIO) and then 
(for my ARM platform) does a remap.
The same code from the BDI config file is also in hal_platform_setup.h, 
but it has a define before it: #if defined(CYG_HAL_STARTUP_ROM) || 
defined(CYG_HAL_STARTUP_ROMRAM). This because RAM mode was made for 
RedBoot loading the image (after having initialized the processor).
So you need to change the BDI config file to change wait states and so on.

I have tried using ROM and ROMRAM images to debug, and with and without 
initilizing the processor in the binary, but my conclusion was: use ecos 
RAM mode to debug.

There is 1 thing to take car of: in RAM mode, by default the VVT 
initializing code is not compiled (because RAM mode was made for RedBoot 
that initializes the VVT).
Therefor I made another ecos startup mode (my ecos tweak for the BDI): 
JTAGRAM. In attach my settings related to RAM mode (I think only the VVT 
one is really needed.)
Mark: with the BDI there is a trick to use normal RAM mode: do 'reset 
run', then 'sleep 1 [s]' and only then 'reset halt' and then load the 
code: this way Redboot starts up for a short while long enough to fill 
the VVT.

I hope this addresses your problem..

Kind regards,
Jürgen

[-- Attachment #2: RAM.sh --]
[-- Type: application/x-sh, Size: 706 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss