[ECOS] STM32 interrupt definitions

[ECOS] STM32 interrupt definitions

[Simon Kallweit]

Hi

Chris Holgate discovered a little inconsistency in the interrupt vector 
definitions, we have:

#define CYGNUM_HAL_INTERRUPT_DMA0_CH1           
(11+CYGNUM_HAL_INTERRUPT_EXTERNAL)
#define CYGNUM_HAL_INTERRUPT_DMA0_CH2           
(12+CYGNUM_HAL_INTERRUPT_EXTERNAL)
...

and

#define CYGNUM_HAL_INTERRUPT_DMA2_CH1           
(56+CYGNUM_HAL_INTERRUPT_EXTERNAL)
#define CYGNUM_HAL_INTERRUPT_DMA2_CH2           
(57+CYGNUM_HAL_INTERRUPT_EXTERNAL)
...

In the STM32 reference manual the first set is named only DMA, the 
second set DMA2, which seems inconstant too. Can we agree to call them 
DMA1/DMA2?

Simon

-- 
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] STM32 interrupt definitions

[Chris Holgate]

On Mon, 2008-11-24 at 13:57 +0100, Simon Kallweit wrote:
> Hi
> 
> Chris Holgate discovered a little inconsistency in the interrupt vector 
> definitions, we have:
> 
> #define CYGNUM_HAL_INTERRUPT_DMA0_CH1           
> (11+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> #define CYGNUM_HAL_INTERRUPT_DMA0_CH2           
> (12+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> ...
> 
> and
> 
> #define CYGNUM_HAL_INTERRUPT_DMA2_CH1           
> (56+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> #define CYGNUM_HAL_INTERRUPT_DMA2_CH2           
> (57+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> ...
> 
> In the STM32 reference manual the first set is named only DMA, the 
> second set DMA2, which seems inconstant too. Can we agree to call them 
> DMA1/DMA2?

I suspect that this is probably a typo in ST's list of interrupt
vectors, since elsewhere in the reference document the two DMA
controllers are consistently referred to as DMA1 and DMA2.

On a related note, in my current DMA register map I've used the
following definitions for accessing the per-channel registers:

#define CYGHWR_HAL_STM32_DMA_CCR(__x)           (0x14*(__x)-0x0C)
#define CYGHWR_HAL_STM32_DMA_CNDTR(__x)         (0x14*(__x)-0x08)
#define CYGHWR_HAL_STM32_DMA_CPAR(__x)          (0x14*(__x)-0x04)
#define CYGHWR_HAL_STM32_DMA_CMAR(__x)          (0x14*(__x))

This allows me to use a common DMA setup function, parameterised by
channel number.  The question is whether this type of thing is
considered bad form or too obtuse to be included in the main register
map.

Chris.


-- 
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] STM32 interrupt definitions

[Nick Garnett]

Simon Kallweit <simon.kallweit@intefo.ch> writes:

> Hi
> 
> Chris Holgate discovered a little inconsistency in the interrupt
> vector definitions, we have:
> 
> #define CYGNUM_HAL_INTERRUPT_DMA0_CH1
> (11+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> #define CYGNUM_HAL_INTERRUPT_DMA0_CH2
> (12+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> ...
> 
> and
> 
> #define CYGNUM_HAL_INTERRUPT_DMA2_CH1
> (56+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> #define CYGNUM_HAL_INTERRUPT_DMA2_CH2
> (57+CYGNUM_HAL_INTERRUPT_EXTERNAL)
> ...
> 
> In the STM32 reference manual the first set is named only DMA, the
> second set DMA2, which seems inconstant too. Can we agree to call them
> DMA1/DMA2?

That seems like a sensible thing to do.

This is partly down to ST's annoying habit of numbering devices from 1
rather that 0.

I'll check in a fix for this when I apply your recent patches.


-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071


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

[ECOS] Redboot hung after fconfig update (y/n)? y

[krj]

I am using Micron DDR MT46H32M32LF on i.mx31 platform. After running redboot, I am seeing a hang after the following message:

Update RedBoot hon-volatile configuration - continue (y/n)? y
"...  Read from 0x07ee0000-0x07eff000 at 0x000800000: . "


      

-- 
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] Redboot hung after fconfig update (y/n)? y

[Chris Zimman]

> I am using Micron DDR MT46H32M32LF on i.mx31 platform. After running
> redboot, I am seeing a hang after the following message:
> 
> Update RedBoot hon-volatile configuration - continue (y/n)? y
> "...  Read from 0x07ee0000-0x07eff000 at 0x000800000: . "

There is almost no useful information in this message that suggests that you
have in any way tried to figure out what the problem is.
By the read of your post, it seems like you expect someone to go dig out a
data sheet for the MT46H32, ask you what your bus settings for the DDR
controller are, 
and basically debug this problem for you.  If that's what you're after, go to
eCosCentric and pay them for platform support.
 
The iMX31 is not a supported platform at this time, and thus has received
little to no testing.

I would suggest that you either run Redboot inside of a JTAG debugger or add
a lot of instrumentation to the code to see where the crash is occurring.

Really, because you're working with this sort of one off version of Redboot,
you should be talking to Freescale about these issues since they support it.
In the past, their Redboot ports (eg. for the iMX family) were very kludgy
and not particularly well tested.

--Chris

--
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] Redboot hung after fconfig update (y/n)? y

[Gary Thomas]

krj wrote:
> 
> I am using Micron DDR MT46H32M32LF on i.mx31 platform. After running redboot, I am seeing a hang after the following message:
> 
> Update RedBoot hon-volatile configuration - continue (y/n)? y
> "...  Read from 0x07ee0000-0x07eff000 at 0x000800000: . "

Very little to go on and oh, so many possibilities...

First of all, this platform is not in the public tree, so there's
not much we can say about it.  You probably need to talk to
FreeScale about your issues.

Also, this device is NAND (hence the 'Read from' message)
which also complicates life.  Is it the same device as what
the [default] FreeScale platform uses?

Finally, you didn't say if the FLASH functions work at all.
For example, can you run 'fc -l' or 'fi li' or 'fi cr'?


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
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] Redboot hung after fconfig update (y/n)? y

[krj]

--- On Tue, 11/25/08, Gary Thomas <gary@mlbassoc.com> wrote:

> From: Gary Thomas <gary@mlbassoc.com>
> Subject: Re: [ECOS] Redboot hung after fconfig update  (y/n)? y
> To: krjaz@yahoo.com
> Cc: "eCos Disuss" <ecos-discuss@ecos.sourceware.org>
> Date: Tuesday, November 25, 2008, 3:58 AM
> krj wrote:
> > 
> > I am using Micron DDR MT46H32M32LF on i.mx31 platform.
> After running redboot, I am seeing a hang after the
> following message:
> > 
> > Update RedBoot hon-volatile configuration - continue
> (y/n)? y
> > "...  Read from 0x07ee0000-0x07eff000 at
> 0x000800000: . "
> 
> Very little to go on and oh, so many possibilities...
> 
> First of all, this platform is not in the public tree, so
> there's
> not much we can say about it.  You probably need to talk to
> FreeScale about your issues.
> 
> Also, this device is NAND (hence the 'Read from'
> message)
> which also complicates life.  Is it the same device as what
> the [default] FreeScale platform uses?
> 
> Finally, you didn't say if the FLASH functions work at
> all.
> For example, can you run 'fc -l' or 'fi li'
> or 'fi cr'?
> 
> 
The nand flash functions do work. But you are correct, much of the code and issues may be related to the software provided outside the public tree and is not applicable to this forum.

There is recent news, however, concerning the use of Micron DDR MT46H32M32LF on i.mx31. Perhaps this component is not completely supported or on the do not use list.

cheers

> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> 
> -- 
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive:
> http://ecos.sourceware.org/ml/ecos-discuss


      

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