Il 08/02/2013 07:32, 42Bastian ha scritto: >
>
> Hi
>
> > 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.
>
> Hmm, so why does the NXP CGU_init switch the CPU only to 72MHz?
> You can't assume that CGU_init() is correct. Make a try with the
copy I
sent some days ago, in LPC43xx clocks setup is a little bit complicated
and if you don't read very carefully the user manual can become a
nightmare. Generally speaking with the wrong setup you can't be able to
drive the EMC at same clock frequency of the cpu. There are 2 clocks
that may drive the EMC: CLK_M4_EMC and CLK_M4_EMC_DIV.
The 1st can run at the same frequency of BASE_M4_CLK that for a LPC4357
is 204MHz so you could drive a SDRAM at the same frequency. The problem
is that 120MHx SDRAM are more common than others so the EMC and CGU
setup may be written to 204/2 = 102MHz. The problem is that in
evaluation boards if the vendor finds different SDRAM at higher
frequencies it is difficult that updates the examples.
But you can program EMC to be driven from the M4 CLK. > --
> 42Bastian
> +
> | http://www.sciopta.com
> | Fastest direct message passing kernel.
> | IEC61508 certified.
> +
> 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.
Hmm, so why does the NXP CGU_init switch the CPU only to 72MHz?
Hi > 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.
Same with me, only that in my case, the debugger looses connection to the
chip. Running w/o debugger does no crash (but of course SDRAM does no work
either).
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
Reply by 42Bastian●February 8, 20132013-02-08
Hi MD
> 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.
> 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.
There are a various number of CGU_init() functions out there and every one
is a bit different.
Anyway, EA confirmed that the board does only run 144/72 (or as my tests
show 96/96).
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
Reply by "M. Manca"●February 7, 20132013-02-07
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.
> > > > +
> > > >
> > >
> > >
> >
> >
> >
> >
> >
Reply by dittrichm07●February 7, 20132013-02-07
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.
> > > +
> > >
> >
> >
>
Reply by "M. Manca"●February 7, 20132013-02-07
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.
> > +
> >
