Il 05/02/2013 07:24, Vladimir Ljaschko ha scritto:
>
>
> Hi,
>
> >>you should rise the refresh frequency and see if solves the
> >>problem.
>
> We did it without success.
> And how refresh could be a reason that data written in one cell
> influences on the other cell?
>
First you should quickly set the EMC correctly, you should copy a
working setup that should be provided in the example of your
compiler/IDE or by NXP examples (no matter if the frequency is lower) to
debug your sw so you can distinguish between EMC/hw errors and sw errors.
Visit www.lpcware.com and you can download some examples. I attached the
working example for SDRAM I used (please say me if you receive the
attachment) hoping could help you. If you need the LPC4300 library you
can download the KEIL MDK evaluation rel.
> >>>I had no problems related to DRAM when I debugged LPC4357 with
> the Hitex
>
> My congratulation!
> I don't exclude stupid mistake in init code, but I lost hope to find it.
>
> Best regards
> Vladimir
>
> ----- Original Message -----
> From: M. Manca
> To: l...
> Sent: Monday, February 04, 2013 1:45 PM
> Subject: Re: [lpc2000] LPC4357 && 204MHz && SDRAM ??
>
> Il 04/02/2013 10:17, 42Bastian ha scritto:
> >
> >
> > Hi Vladimir
> >
> > >>> Which speed?
> > > 120 MHz and code from NXP, implemented by ourself (there was not any
> > project from Keil).
> > > So, NXP code must work, at least in some conditions.
> >
> > 120MHz Core clock and 60MHz EMC?
> >
> > >>> No, not sure at all. The simple EA SDRAM test passes, but I see
> > strange
> > > values if I fill the SDRAM via Debugger. But then, can I trust the
> > debugger.
> > > Yes, topic of trust the debugger is way to nowhere :)
> > > We did following test:
> > > - simple block write/block read test runs in main() and checks area
> > A of SDRAM
> > > - few hundreds write/read operations into area B of SDRAM
> > implemented into system tick ISR
> > > Result: test fails
> > > If to remove all operations with SDRAM in ISR, then result=OK
> >
> If there is no sw error this should be a problem related to refresh DRAM
> frequency you should rise the refresh frequency and see if solves the
> problem. I had no problems related to DRAM when I debugged LPC4357 with
> the Hitex beta board.
> >
> > > I kindly ask you to run similar test to be sure are our problems
> > similar or we have two different situations. Thanks.
> >
> > I will try it tomorrow.
> >
> > >>> If I choose 1:2 ration, I can only go up to 144MHz?
> > > Why 144?
> > > With 1:2 ratio you can use 204 CPU clock and 104 SDRAM clock.
> >
> > Yes. That's where I am not sure I am hunting false bugs.
> >
> > If I uses 96MHz core clock and 1:1 ratio for EMC, the SDRAM "seems" to
> > work (at least the memory can be seen).
> > If I uses 1:2 ration, I cannot go higher with the core clock than 144MHz
> > (giving 72MHz to the EMC).
> >
> > Cheers
> >
> > --
> > 42Bastian
> > +
> > | http://www.sciopta.com
> > | Fastest direct message passing kernel.
> > | IEC61508 certified.
> > +
> >
> >
>
>



Start a New Thread

Hi
> First you should quickly set the EMC correctly, you should copy a
> working setup that should be provided in the example of your

:-) Good joke. I used the example from EA and it is not working correctly.
Currently I go trough every parameter and check them (and some are already
wrong).

> working example for SDRAM I used (please say me if you receive the

No, the attachment was deleted.

--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
Start a New Thread

Hi

> Visit www.lpcware.com and you can download some examples. I attached the
> working example for SDRAM I used (please say me if you receive the
> attachment) hoping could help you. If you need the LPC4300 library you
> can download the KEIL MDK evaluation rel.

Thanks for the example code. It is like all the other codes I have seen so
far.

Slowly I have the impression something is really missing something
essential in my code.

I setup the clocks Core/EMC 96MHz/96MHz, or 156MHz/78MHz.
First one works, second one doesn't even though the the EMC clock is lower.
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
Start a New Thread

Il 05/02/2013 13:07, 42Bastian ha scritto:
>
>
> Hi
>
> > Visit www.lpcware.com and you can download some examples. I attached the
> > working example for SDRAM I used (please say me if you receive the
> > attachment) hoping could help you. If you need the LPC4300 library you
> > can download the KEIL MDK evaluation rel.
>
> Thanks for the example code. It is like all the other codes I have seen so
> far.
>
the newest were based on that code. During the earlier phase of LPC4300
hw/sw development/debug NXP, Hitex, Keil and a team of 10 experts worked
all together to deliver working code and find bugs. Also if my attention
was to realize and optimize the 2 core communications I used all memory
resources on the LPC4300 Development Kit (at that time it had a
preliminary rel. of the Hitex board).

I think that the problem you are experiencing (assuming that the hw
design is correct) should be related to clock/divider/EMC clock setups.
You could download my application example at
http://www.lpcware.com/content/contribproj/MassimoManca-lpc4300ex and
see if there are some differences in the registers setup. Take care that
is designed for Keil C compiler.
> Slowly I have the impression something is really missing something
> essential in my code.
>
> I setup the clocks Core/EMC 96MHz/96MHz, or 156MHz/78MHz.
> First one works, second one doesn't even though the the EMC clock is
> lower.
>
> --
> 42Bastian
> +
> | http://www.sciopta.com
> | Fastest direct message passing kernel.
> | IEC61508 certified.
> +



Start a New Thread

Hi

> I think that the problem you are experiencing (assuming that the hw
> design is correct) should be related to clock/divider/EMC clock setups.
> You could download my application example at
> http://www.lpcware.com/content/contribproj/MassimoManca-lpc4300ex and
> see if there are some differences in the registers setup. Take care that
> is designed for Keil C compiler.

The project is missing some files. For example, where is hitex_CGU_init()
defined.

I found one CDL_CGU_init(), but also with this one, I cannot get it to work.

Do you really run 204/102 MHz in your example?

Cheers
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
Start a New Thread

Il 05/02/2013 16:44, 42Bastian ha scritto:
>
>
> Hi
>
> > I think that the problem you are experiencing (assuming that the hw
> > design is correct) should be related to clock/divider/EMC clock setups.
> > You could download my application example at
> > http://www.lpcware.com/content/contribproj/MassimoManca-lpc4300ex and
> > see if there are some differences in the registers setup. Take care that
> > is designed for Keil C compiler.
>
> The project is missing some files. For example, where is hitex_CGU_init()
> defined.
>
The project is complete. As I said you should download an evaluate
version of Keil that should have everything. In www.lpcware. there is
also a zip archive containing all the Hitex BSDs, may be that Hitex
updated it only on their web sites you can check also there.
> I found one CDL_CGU_init(), but also with this one, I cannot get it to
> work.
>
> Do you really run 204/102 MHz in your example?
>
Yes, I run at the maximum clock possible and also I tried also to over
clock the mcu.
> Cheers
> --
> 42Bastian
> +
> | http://www.sciopta.com
> | Fastest direct message passing kernel.
> | IEC61508 certified.
> +



Start a New Thread

Hi 42Bastian,

I am seeing similar issues. I started work on a MCB4300 (LPC4350) and had the SDRAM working great (as I remember...) running at 204MHz core and 102MHz EMC.

Now working with my own board with a LPC4337 installed, running the same code with some tweaks, I can run 96/96 but not 192/96! Which does not make sense to me.

I get read errors doing a simple "fill incremental values then compare" test. I can run 108/108 and 120/60, but not 120/120. I have not cranked it up to see where the /2 scenario starts to fail, 96/96 is stable and I can continue other bring-up work.

Unfortunately, two variables have changed: the board and the uC. So I don't really know what is to blame yet, and am not looking forward to the HW debug... I was hoping to just pick up a new LPC43x7 based dev board to remove one those variables, but given your issues I am not quite sure.

I can say that I have seen some very weird difference between the 4350 and 4337, debugger related and otherwise, see: http://www.lpcware.com/content/forum/sdram-init-fails-unless-under-debugger-0

Thanks,
MD

--- In l..., 42Bastian wrote:
>
> Hi,
>
> I am currently fighting to get an EA LPC4357 OEM board to work with 204MHz
> core clock, but EMC or SDRAM is only working up to 144MHz.
>
> Anyone got the LPC4357 work with > 144MHz?
>
> Yes, the EMC clock is set to /2 otherwise I can only go up to 96MHz.
> Strange, the register CLK_EMCDIV_CFG is written with 0x21 and changes to
> 0x08000001, which is not a documented value.
>
> Any hint?
> --
> 42Bastian
>
> --
> 42Bastian
> +
> | http://www.sciopta.com
> | Fastest direct message passing kernel.
> | IEC61508 certified.
> +
>

Start a New Thread

Il 07/02/2013 20:19, dittrichm07 ha scritto:
>
>
> Hi 42Bastian,
>
> I am seeing similar issues. I started work on a MCB4300 (LPC4350) and
> had the SDRAM working great (as I remember...) running at 204MHz core
> and 102MHz EMC.
>
> Now working with my own board with a LPC4337 installed, running the
> same code with some tweaks, I can run 96/96 but not 192/96! Which does
> not make sense to me.
>
> I get read errors doing a simple "fill incremental values then
> compare" test. I can run 108/108 and 120/60, but not 120/120. I have
> not cranked it up to see where the /2 scenario starts to fail, 96/96
> is stable and I can continue other bring-up work.
>
> Unfortunately, two variables have changed: the board and the uC. So I
> don't really know what is to blame yet, and am not looking forward to
> the HW debug... I was hoping to just pick up a new LPC43x7 based dev
> board to remove one those variables, but given your issues I am not
> quite sure.
>
> I can say that I have seen some very weird difference between the 4350
> and 4337, debugger related and otherwise, see:
> http://www.lpcware.com/content/forum/sdram-init-fails-unless-under-debugger-0
>
Take care also to debug a little bit the hw, a good idea should be to
put a scope to the enable and data bus while you are addressing a test
routine as walking ones or some patterns (0x55, 0xaa and so on). The
forum advice shouldn't reveal an error on EMC, in my opinion is more
probable that the initialization procedure is wrong because to download
code to SDRAM from debugger the debugger needs a driver that should
initialize the SDRAM properly. If this is the situation could be a good
idea to download the application in SDRAM using the debugger, compare
the object code between debugger and original file, if they will be the
same the best thing to do is to see the EMC register content, write them
down and then study the differences and then try to use the same init
values as a starting point.

There are come ready modules to setup SDRAM/EMC, I posted one some days
ago see if it can help you. Remember that LPC43xx and LPC18xx aren't
very simple to setup but they are very powerful microcontroller families.
> Thanks,
> MD
>
> --- In l... ,
> 42Bastian wrote:
> >
> > Hi,
> >
> > I am currently fighting to get an EA LPC4357 OEM board to work with
> 204MHz
> > core clock, but EMC or SDRAM is only working up to 144MHz.
> >
> > Anyone got the LPC4357 work with > 144MHz?
> >
> > Yes, the EMC clock is set to /2 otherwise I can only go up to 96MHz.
> > Strange, the register CLK_EMCDIV_CFG is written with 0x21 and changes to
> > 0x08000001, which is not a documented value.
> >
> > Any hint?
> > --
> > 42Bastian
> >
> > --
> > 42Bastian
> > +
> > | http://www.sciopta.com
> > | Fastest direct message passing kernel.
> > | IEC61508 certified.
> > +
> >



Start a New Thread

Thanks Massimo,

My init is much like that found in sw.lpcware.com repo and in LPCOpen v1.00. BUT... I just re-compared that code against mine (and my schematic...), I realized that we are using CLK1/EMC_CKEOUT1 (I remember reading somewhere it had better latency/delays than CLK0???). My pinmux init code was setting up EMC_CKEOUT0, not EMC_CKEOUT1! I am surprised it ran at all!

I can only guess that the 192/96 scenario has some extra noise (vs 96/96) due to the higher core clock, and perhaps was glitching signal from the uninitialized clock enable output... 192/96 now passes my minimal test, but 204/102 does not. Now it's time to break out the scope! :)

My lpcware post might have been confusing... I never downloaded code to the SDRAM via the debugger. The problem was accessing EMC (just a *((uint32_t*)0x28000000) in the code) would crash the chip, no exception vectors would run. The debugger clouded the issue, because as long I was running under the debugger everything worked fine. Code was always running from internal flash. Removing a "LPC_RGU->RESET_CTRL1 = 1ul << 12;" from the start of my uart0 init routine stopped the crashes on SDRAM read.

From the user manual I don't think this should happen, it was odd... I am curious why it happened, but I realize that it is probably some of my ancillary code elsewhere that is misbehaving, but it's behind me now... until it shows up again of course :)

Thanks again,
MD

--- In l..., "M. Manca" wrote:
>
> Il 07/02/2013 20:19, dittrichm07 ha scritto:
> >
> >
> >
> >
> > Hi 42Bastian,
> >
> > I am seeing similar issues. I started work on a MCB4300 (LPC4350) and
> > had the SDRAM working great (as I remember...) running at 204MHz core
> > and 102MHz EMC.
> >
> > Now working with my own board with a LPC4337 installed, running the
> > same code with some tweaks, I can run 96/96 but not 192/96! Which does
> > not make sense to me.
> >
> > I get read errors doing a simple "fill incremental values then
> > compare" test. I can run 108/108 and 120/60, but not 120/120. I have
> > not cranked it up to see where the /2 scenario starts to fail, 96/96
> > is stable and I can continue other bring-up work.
> >
> > Unfortunately, two variables have changed: the board and the uC. So I
> > don't really know what is to blame yet, and am not looking forward to
> > the HW debug... I was hoping to just pick up a new LPC43x7 based dev
> > board to remove one those variables, but given your issues I am not
> > quite sure.
> >
> > I can say that I have seen some very weird difference between the 4350
> > and 4337, debugger related and otherwise, see:
> > http://www.lpcware.com/content/forum/sdram-init-fails-unless-under-debugger-0
> >
> Take care also to debug a little bit the hw, a good idea should be to
> put a scope to the enable and data bus while you are addressing a test
> routine as walking ones or some patterns (0x55, 0xaa and so on). The
> forum advice shouldn't reveal an error on EMC, in my opinion is more
> probable that the initialization procedure is wrong because to download
> code to SDRAM from debugger the debugger needs a driver that should
> initialize the SDRAM properly. If this is the situation could be a good
> idea to download the application in SDRAM using the debugger, compare
> the object code between debugger and original file, if they will be the
> same the best thing to do is to see the EMC register content, write them
> down and then study the differences and then try to use the same init
> values as a starting point.
>
> There are come ready modules to setup SDRAM/EMC, I posted one some days
> ago see if it can help you. Remember that LPC43xx and LPC18xx aren't
> very simple to setup but they are very powerful microcontroller families.
> >
> >
> > Thanks,
> > MD
> >
> > --- In l... ,
> > 42Bastian wrote:
> > >
> > > Hi,
> > >
> > > I am currently fighting to get an EA LPC4357 OEM board to work with
> > 204MHz
> > > core clock, but EMC or SDRAM is only working up to 144MHz.
> > >
> > > Anyone got the LPC4357 work with > 144MHz?
> > >
> > > Yes, the EMC clock is set to /2 otherwise I can only go up to 96MHz.
> > > Strange, the register CLK_EMCDIV_CFG is written with 0x21 and changes to
> > > 0x08000001, which is not a documented value.
> > >
> > > Any hint?
> > > --
> > > 42Bastian
> > >
> > > --
> > > 42Bastian
> > > +
> > > | http://www.sciopta.com
> > > | Fastest direct message passing kernel.
> > > | IEC61508 certified.
> > > +
> > >
> >
> >
>

Start a New Thread

Il 07/02/2013 23:16, dittrichm07 ha scritto:
>
>
> Thanks Massimo,
>
> My init is much like that found in sw.lpcware.com repo and in LPCOpen
> v1.00. BUT... I just re-compared that code against mine (and my
> schematic...), I realized that we are using CLK1/EMC_CKEOUT1 (I
> remember reading somewhere it had better latency/delays than CLK0???).
> My pinmux init code was setting up EMC_CKEOUT0, not EMC_CKEOUT1! I am
> surprised it ran at all!
>
You did a good job, I spent a couple of months debugging LPC43xx,
libraries, tools and writing my application examplesfor NXP exercising
the dual core communications using every type of memory on the Hitex
board so I feel it is a power horse, very configurable but of course it
needs also more attention to every detail.
> I can only guess that the 192/96 scenario has some extra noise (vs
> 96/96) due to the higher core clock, and perhaps was glitching signal
> from the uninitialized clock enable output... 192/96 now passes my
> minimal test, but 204/102 does not. Now it's time to break out the
> scope! :)
>
> My lpcware post might have been confusing... I never downloaded code
> to the SDRAM via the debugger. The problem was accessing EMC (just a
> *((uint32_t*)0x28000000) in the code) would crash the chip, no
> exception vectors would run. The debugger clouded the issue, because
> as long I was running under the debugger everything worked fine. Code
> was always running from internal flash. Removing a
> "LPC_RGU->RESET_CTRL1 = 1ul << 12;" from the start of my uart0 init
> routine stopped the crashes on SDRAM read.
>
> >From the user manual I don't think this should happen, it was odd...
> I am curious why it happened, but I realize that it is probably some
> of my ancillary code elsewhere that is misbehaving, but it's behind me
> now... until it shows up again of course :)
>
> Thanks again,
> MD
>
> --- In l... , "M.
> Manca" wrote:
> >
> > Il 07/02/2013 20:19, dittrichm07 ha scritto:
> > >
> > >
> > >
> > >
> > > Hi 42Bastian,
> > >
> > > I am seeing similar issues. I started work on a MCB4300 (LPC4350) and
> > > had the SDRAM working great (as I remember...) running at 204MHz core
> > > and 102MHz EMC.
> > >
> > > Now working with my own board with a LPC4337 installed, running the
> > > same code with some tweaks, I can run 96/96 but not 192/96! Which does
> > > not make sense to me.
> > >
> > > I get read errors doing a simple "fill incremental values then
> > > compare" test. I can run 108/108 and 120/60, but not 120/120. I have
> > > not cranked it up to see where the /2 scenario starts to fail, 96/96
> > > is stable and I can continue other bring-up work.
> > >
> > > Unfortunately, two variables have changed: the board and the uC. So I
> > > don't really know what is to blame yet, and am not looking forward to
> > > the HW debug... I was hoping to just pick up a new LPC43x7 based dev
> > > board to remove one those variables, but given your issues I am not
> > > quite sure.
> > >
> > > I can say that I have seen some very weird difference between the 4350
> > > and 4337, debugger related and otherwise, see:
> > >
> http://www.lpcware.com/content/forum/sdram-init-fails-unless-under-debugger-0
> > >
> > Take care also to debug a little bit the hw, a good idea should be to
> > put a scope to the enable and data bus while you are addressing a test
> > routine as walking ones or some patterns (0x55, 0xaa and so on). The
> > forum advice shouldn't reveal an error on EMC, in my opinion is more
> > probable that the initialization procedure is wrong because to download
> > code to SDRAM from debugger the debugger needs a driver that should
> > initialize the SDRAM properly. If this is the situation could be a good
> > idea to download the application in SDRAM using the debugger, compare
> > the object code between debugger and original file, if they will be the
> > same the best thing to do is to see the EMC register content, write them
> > down and then study the differences and then try to use the same init
> > values as a starting point.
> >
> > There are come ready modules to setup SDRAM/EMC, I posted one some days
> > ago see if it can help you. Remember that LPC43xx and LPC18xx aren't
> > very simple to setup but they are very powerful microcontroller
> families.
> > >
> > >
> > > Thanks,
> > > MD
> > >
> > > --- In l... ,
> > > 42Bastian wrote:
> > > >
> > > > Hi,
> > > >
> > > > I am currently fighting to get an EA LPC4357 OEM board to work with
> > > 204MHz
> > > > core clock, but EMC or SDRAM is only working up to 144MHz.
> > > >
> > > > Anyone got the LPC4357 work with > 144MHz?
> > > >
> > > > Yes, the EMC clock is set to /2 otherwise I can only go up to 96MHz.
> > > > Strange, the register CLK_EMCDIV_CFG is written with 0x21 and
> changes to
> > > > 0x08000001, which is not a documented value.
> > > >
> > > > Any hint?
> > > > --
> > > > 42Bastian
> > > >
> > > > --
> > > > 42Bastian
> > > > +
> > > > | http://www.sciopta.com
> > > > | Fastest direct message passing kernel.
> > > > | IEC61508 certified.
> > > > +
> > > >
> > >
> > >
> >
> >
> >
> >
> >



Start a New Thread