Program Not Running (SOLVED)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Program Not Running (SOLVED)

1,476 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jnewell on Mon Aug 26 11:23:07 MST 2013
Hello everyone,

I've got a problem that I'm completely stumped about.

My setup is a custom LPC1768 board.

I've got the ISP pulled high with a 10k resistor, with a switch in line to ground it for using FlashMagic.

FlashMagic flashes and reads back what was flashed without any problems, but when I go to reset, nothing happens on the board (program wise).
Also, through the UART I'm able to send commands to the ISP command line without any problems.

Now, on the other hand, using LPCXpresso, it will say that it programmed the chip just fine and states that its running, but isn't. When I stop it it gives addresses that are located in the bootROM. (This shouldn't be the case considering my ISP is pulled high).

The code uploads and runs perfectly on my evaluation board (RDB1768).

Any idea on what could be the problem? Is there any possibility that in one of the times I was flashing the chip, the bootROM got corrupted or something?

Any help/suggestions would be appreciated.

Thanks,
Josh
Labels (1)
0 Kudos
10 Replies

1,263 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by sridip on Mon Jun 06 22:16:36 MST 2016
what to do when the mcu is in one of the deep sleep modes and debug gets stuck? i am using an lpc54102 in my own custom board. the error says that certain memory accsess is restricted and from what i get is that it has gone to one of the sleep modes. i did flash the pinint example code in it to operate the sleep mode.
0 Kudos

1,263 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jnewell on Wed Sep 04 12:42:01 MST 2013
Well I came to the conclusion that there is something that was overlooked on the schematic.
I planned on using the internal RC oscillator onboard the LPC1768 just like the RDB1768 eval board, so I left the XTAL1 and XTAL2 pins floating.
Disabling the CMSIS library (removing from the build settings in LPCXpresso) and rebuilding allowed my processor to run (but at a measly 4MHz because it wasn't upped to 100MHz when the CMSIS library isn't used).
They either need to be terminated or have a crystal connected (12MHz) in order for it to get through the PLL setup correctly.

For some reason, in the CMSIS setup code when the PLL's are being setup in SystemInit(), it gets stuck in the loop waiting for PLL1. After setting the PLL1 flag to zero(disabling), my processor runs!

Seems that not every problem is solved with the Reset and ISP!

-Josh





0 Kudos

1,263 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jnewell on Tue Sep 03 11:52:43 MST 2013
I think I'm on to something. I was reading through UM10360 and came across this:
When initializing the Ethernet block, it is important to first configure the PHY and insure that the reference clocks (ENET_REF_CLK signal in RMII mode) are present at the external pins and connected to the EMAC module(selecting the appropriate pins using the PINSEL registers) prior to continuing with Ethernet configuration. Otherwise the CPU can become locked and no further functionality will be possible. This will cause JTAG lose communication with the target, if debug mode is being used.

I went to check the PHY Crystal (for the LAN8720A) to make sure its oscillating, and it is not.
I've got an inverter (SN74LVCG104DBVR) connected to REFCLKO from the PHY (pin 1 and 2 connected to REFCLK0(should be 50Mhz out of the PHY), pin 3 connected to GND, pin 4 connected to CLKOUT (going to LPC1768), and pin 5 connected to 3.3V) I'm using a standard 25mhz crystal with 30pf caps on each side with a 1M resistor in between. Any idea on why it wouldn't be oscillating?

Thanks,
Josh
0 Kudos

1,263 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Tue Sep 03 09:28:35 MST 2013
The debug driver will report status-poll errors when it loses communication with the debug interface on the chip. This will normally be because
- the target has gone into one of the sleep modes and has disabled debug
- the target gets reset
- the target power is removed
- the debug connection 'breaks'

The "Failed on connect" is undoubtedly related.

It still looks like you have some problems in your board design.
0 Kudos

1,263 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jnewell on Tue Sep 03 09:03:25 MST 2013
Well, I've come to some resolution, still having troubles. I can program the processor now, but right after it gets programmed,
I get the error:
16: Target error from status-poll
  16: Target error from status-poll
  System rejected access at location 0xE000EDF0 - verify Population of memory and peripherals

Every few tries I get:
02: Failed on connect
  02: Failed on connect
  Cannot find selected MEM-AP (check target power)
  Emu(1): Conn&Reset. Was: None. DpID: 2BA01477. Info: FTVTJI31A

Anyone have any idea on why I am getting these errors?

Thanks,
Josh

0 Kudos

1,263 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jnewell on Tue Aug 27 06:55:23 MST 2013

I'm starting to think that it is a hardware problem as well, just not exactly sure where the problem is.

I've got a switch connected up to ISP so that I can enter it when I need to, otherwise it is pulled up with a 10k resistor.
It seems to work just fine in that sense, so I know that it is not the ISP pin (P2.10). When I don't press it, I can't access the processor with FlashMagic, and when I do, it works just fine. I'm able to get the serial number, bootloader version, etc. It also tells me that the CRC is disabled.

Next, I've got a reset IC to create the low reset pulse at startup. According to my oscilliscope, that is working correctly.

The power supply is solid, been using it with multiple designs without issues.


0 Kudos

1,263 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Tue Aug 27 06:44:02 MST 2013
Sounds like you have some kind of hardware problem. I suggest you check ISP, and RESET. Also make sure power supply is stable.
0 Kudos

1,263 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jnewell on Tue Aug 27 06:14:32 MST 2013
Well it is definitely creating the checksum at the correct location 0x1c


make --no-print-directory post-build
Performing post-build steps
arm-none-eabi-size RDB1768cmsis_LedFlash.axf; arm-none-eabi-objcopy -O binary RDB1768cmsis_LedFlash.axf RDB1768cmsis_LedFlash.bin ; checksum -p LPC1768 -d RDB1768cmsis_LedFlash.bin;
   text   data    bss    dec    hexfilename
   1160      0      4   1164    48cRDB1768cmsis_LedFlash.axf
Created checksum 0xfa79f9ef in RDB1768cmsis_LedFlash.bin at offset 0x1c


-Josh
0 Kudos

1,263 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jnewell on Mon Aug 26 14:16:29 MST 2013
Hi,

How do I find out if the flash checksum is correct?

0 Kudos

1,263 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by usb10185 on Mon Aug 26 13:06:18 MST 2013
Hi Josh,

A portion of the BootROM code will always run regardless of the status of the ISP pin. Based on the ISP pin status the BootROM will decide to start ISP or the Application code if valid. Is the flash checksum @address 0x1c correct?

Ken
0 Kudos