LPC4330 and SPIFI questions

Comments

33 comments

  • Avatar
    Michael Johnson

    Hi Matt,

    You'll need to create a board specific project - try the ngx lpc 4300 explorer.

     

    Regards

    Michael

    0
    Comment actions Permalink
  • Avatar
    Matt

    Thanks Michael.  I pulled that up and will alter as needed.  Quick follow up:  the file "NGX_LPC4330_Xplorer_Target.js" file is in the explorer window, but excluded from the project..  What is this file for?  Just trying to determine how the build works so I know where to alter as needed...

    Thanks again,
    Matt

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    That will be needed remove the exclude from build - it will set the pins up for the spifi block.

    0
    Comment actions Permalink
  • Avatar
    Matt

    Got it...thanks Michael,
    Matt

    0
    Comment actions Permalink
  • Avatar
    Matt

    Hi MIchael,

    Hopefully, this is just a dumb issue.  I got the SPIFI project working, no issue.  However, I tried doing some simple interrupts on an LPC4330 and am having trouble.  I tried to boil it down for you in the attached test project.

    I think you can run it on any LPC4330 (or really any 43xx).  It does NOT use SPIFI for this example.  I reverted back to your core project that is just a RAM based solution.

    Here is the problem.  While I can set the registers for TIMER0 o.k., there are two things not happening.  1) ISR does not fire even though the IR register indicates that the conditions for the ISR firing have been met and 2) If I poll the IR register until it is a match, I cannot clear that register.  So even though the other timer registers reflect values written to them, the IR register seems impervious to writes / clears!

    Could you take a quick look and see if I'm missing something?  I do alot of work with the LPC17xx series and Crossworks...I hope I'm just missing something and there isn't some dual core issue biting me that I'm unaware of.

    Thanks,
    Matt

    p.s.  You'll see a "USE_CUSTOM_BOARD" define in there.  That is turned off, it is for our custom board.  The code in there was supposed to fire off on a button push (GPIO interrupt) and it fails also, which is why I went for the Timer demo for confirmation.  But polling the button push works and I can trigger another output via the button push, so in general the chip seems to be responding to the code correctly, except for this ISR issue.

     

     

    0
    Comment actions Permalink
  • Avatar
    Matt

    OK, so new information.  I switched to an M0 project.  All the expected ISR functionality seems to work.  So the LPC4330 has two cores, the M4 and M0.  I know there are dual core examples.  But I was under the impression that they shared the NVIC / ISR peripherals (or can).  

    Can you fill me in on why the M4 version that I attached above doesn't seem to fire off the ISR?

    Thanks Michael,
    Matt

     

    0
    Comment actions Permalink
  • Avatar
    Matt

    Sorry, I misspoke.  Each core has its own NVIC.  So using the same main.c file in my test project above, a M0 core solution works.  An M4 does not.  I looked at your dual core examples and see some other defines like "NESTED_INTERRUPTS" in the project defines, and did a diff between some of the .hzs files.  I tried a few little changes, but can't get the M4 project to fire off interrupts.  It feels like I'm missing some define or something that isn't in the default project perhaps?

    I wouldn't mind just using the M0 core for this particular project, but I was trying to stay away from the headache of figuring out loading the code into the M0 side from SPIFI in the short term.  

    Anyway, any suggestions you have would be greatly appreciated....

    Thanks,
    Matt

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Hi Matt,

    It could be a reset problem - not a good story for the lp4300. If you hard reset then attach the debugger you'll find it stuck in the start up from reset loop. Change the pc to the entry symbol using the debugger and see if things work any better.

     

    Regards

    Michael

    0
    Comment actions Permalink
  • Avatar
    Matt

    Maybe I'm not following....I'm not even trying to boot from SPIFI yet.  I bring the board up with the debugger attached.  I set the project to run from RAM (not SPIFI).  I run the project I have attached as "build and debug".  The project loads (I can break in LPC4300_Startup.s to see its progress).  I am not stuck in the startup from reset loop (at least I'm not tripping the breakpoint I set there).

    I did (after download and run from RAM) stop debugging.  Then I attached the debugger to the running target, stopped the target, set the PC back to the beginning of main() and let it fly.  No change, still don't stop in the ISR.

    But maybe I misunderstood your suggestion?

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Okay - can you change the boot source on the board?

    0
    Comment actions Permalink
  • Avatar
    Matt

    I can boot from USB (DFU)...

    0
    Comment actions Permalink
  • Avatar
    Matt

    Hi Michael,

    It was painful, but today I broke out the latest LPCExpresso GUI and an LPCLink2 I had lying around.  Getting those to play together was the hard part, but after that, I took the same sample code I sent you and created a project from them around it for the M4.  The ISR's all fired off as expected on the board.  

    So I think there must be some kind of project configuration problem in the default setup for this chip in Crossworks?

     

    0
    Comment actions Permalink
  • Avatar
    Matt

    Oh, to be clear....I used the LPC stuff on the same custom board.  The last note seemed to read that I ran code on the LPC link2.  I used the LPCExpresso compiler and debugger to compile.  I used the LPCLink2 as the debugger tool.  And I used the same custom board as the target.

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    I can repeat this on the NGX xplorer board if it has booted from the spi flash. Can you see if you can erase the spi flash on your board? I suspsect that the lpcexpresso/lpclink2 is doing a better job of resetting the device under debug control always a nasty area with NXP chips.

    0
    Comment actions Permalink
  • Avatar
    Matt

    Can you repeat with the RAM only version?  I'd like to keep the SPIFI out of it for now if possible, just to find the root cause.  It is really unclear to me why everything seems to work on the chip hardware control-wise (pin toggling, polling for states, etc) but the ISR's.  How does resetting the device under debug affect this?  Is it something about the vector interrupt table?  Why does the M0 project work? Is it because the M0 reset is handled differently?

    I'll have time later today to look harder at the spi flash erase / handling.  But if you can think of anything else to look at, I'd appreciate it.  We have a Keil license as well that I had to get for a different project, but I'd really, really like to stay away from that tool. (I'm a Rowley fan of course....)

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    I'm talking about a RAM only version. When the chip has booted from SPI flash then the timer interrupts don't trigger for RAM version. If the SPI flash isn't programmed then I suspect the chip stays in the bootloader.

    0
    Comment actions Permalink
  • Avatar
    Matt

    OK, so....you are thinking that the board powers on and that there is some code in SPI flash that lets the system boot up.  Then when we take over with the debugger and load a program to RAM, the chip is in a weird state and doesn't reset properly?  So you want me to erase the SPIFI and see if it will even boot up?  Sorry for being dense, just trying to figure out the path here....

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    I think this is what's happening - we've seen it before with NXP chips.

    0
    Comment actions Permalink
  • Avatar
    Matt

    So what would the LPCExpresso guys be doing that is different and allowing the reset to work correctly?

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    A good question not sure how to answer it.

    0
    Comment actions Permalink
  • Avatar
    Matt

    Hmmmmm...I guess if you can think some more about it then....do you see any more possible activity on your end here?  Any suggestions for me to try?  Do I have to switch tools?

    0
    Comment actions Permalink
  • Avatar
    Matt

    Hi Michael,

    I grabbed a new board, completely clean (no SPIFI code, etc).  First, I ran the RAM only case.  It worked fine (all interrupts were O.K.).  Then I ran the SPIFI version.  It also worked fine.  I will go back and erase the first one and see if I can avoid this problem, but I don't exactly know what it is I'm avoiding.  

    I'm using the core of the NGC Xplorer SPIFI loader as you suggested.  Are there any tools / commands / documentation you can point me at that would perhaps let me do things like erase SPIFI, query it, etc.?  

    I'm just stumbling a little here with this new information.  I don't see why some bit of code in the first boards SPIFI would have any bearing on reset to begin with, and board to board variability is puzzling as well.  

    Any help / thoughts you can provide would be great....

    Thanks,
    Matt

     

    0
    Comment actions Permalink
  • Avatar
    Matt

    And one more clue that I think points to what you are thinking (i.e. something in the reset handling of the chip via Crossworks?).....  

    Per my previous post, I loaded up a fresh board and ran the RAM version of code, then the SPIFI, then the RAM again.  I did not power down between any of them.  They all worked just fine.

    I powered that new board down and re-powered it.  It now behaves just like the first board.  Namely, I can load code and debug with interrupts working, but no ISR's are firing at all.

     

     

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Hi Matt,

    Load the loader solution - there should be link to it in the board support package documentation and download it to see what it is doing - no magic.

    I'll have a look and see if I can figure out what is happening.

    Regards

    Michael

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Hi Matt,

    Try adding the following to the top of the ResetCM4() function in LPC4300_Target.js

    function ResetCM4()
    {
          TargetInterface.resetAndStop(100);
          return;
     }

    and see if this helps.

     

    Regards

    Michael

    0
    Comment actions Permalink
  • Avatar
    Matt

    Hi MIchael,

    That worked!  ISR's are now firing off in the M4 code.  THANKS!

    Can I ask...what did we lose by removing following stuff (now inactive in the LPC4300_Target.js function)...

     

    TargetInterface.pokeWord(0xE000EDF0, 0xA05F0003); // set C_HALT and C_DEBUGEN in DHCSR
    TargetInterface.waitForDebugState(1000);
    TargetInterface.pokeWord(0xE000EDFC, 0x1); // set VC_CORERESET in DEMCR
    TargetInterface.pokeWord(0xE000ED0C, 0x05FA0004); // set SYSRESETREQ in AIRCR
    TargetInterface.waitForDebugState(1000);

    // The boot ROM hasn't run - if it had then...
    // PLL1 to 96Mhz
    TargetInterface.pokeWord(0x40050044, 0x01170881);
    TargetInterface.pokeWord(0x40050044, 0x01170880);
    // Feed PLL1 into IDIVC
    TargetInterface.pokeWord(0x40050050, 0x09000808);
    // Run the Base M3 clock off IDIVC
    TargetInterface.pokeWord(0x4005006C, 0x0e000800);

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Hi Matt,

    If you have a program in the spi flash then it will execute between the debugger resetting the device and stopping it. If that program has been produced by the crossworks build process (and STARTUP_FROM_RESET has not been defined) then it won't be a problem otherwise you'll start debugging in the state when the debugger stopped the device.

    Regards

    Michael

    0
    Comment actions Permalink
  • Avatar
    Matt

    Thanks Michael,

    That makes sense.  Slightly new problem perhaps here.  I finished getting the application to work as expected with the "STARTUP_FROM_RESET" NOT defined.  Once comfortable I wasn't going to lock anything up, I defined this in the pre-processor definition seciton of the project.  I compiled both debug and release versions of the SPIFI project.  Both run under the debugger.  However, when I disconnect the debugger and cycle power, I get no program running.  Any ideas?  Just wondering if this could be somehow related to the SPIFI driver...

     

    0
    Comment actions Permalink
  • Avatar
    Michael Johnson

    Hi Matt,

    Attach the debugger and see what the program is doing.

     

    Regards

    Michael

    0
    Comment actions Permalink
  • Avatar
    Matt

    Hmmmm...here is what happens:

    1) I download code with "startup from reset" defined

    2) Run and debug - no problem with debugger attached (I have some serial output going from it so I know it is operating)

    3) Power down

    4) Power up, with CrossConnect attached.  No serial output / program running.

    5) Attach debugger via SW - as soon as I attach, the serial output begins and I can breakpoint in the code.  No additional download occurred.

    6) Power down

    7) Power up with CrossConnect completely disconnected.  No serial output / program running apparently.

    8) Attach CrossConnect.  No output.

    9) Attach debugger via SW.  Program running.

     

    I have to look at it a little more, but from the nature of my serial output, It seems like the program might be running actually, but no serial output until the CrossConnect is attached via SW.  That doesn't make any sense to me though.  Any thoughts?

    Thanks,
    Matt

    0
    Comment actions Permalink

Please sign in to leave a comment.