I’m having trouble consistently downloading to the development board using the Raven debugger. Can anyone help?
I have had many different unrelated problems using the Raven to download to our devboard, including my current problem where my software works fine if flashed to ROM but does not work when loaded to RAM! Can you be more specific about the behaviour you are seeing?
Are you using the proper power sequence? First power up the board, then the raven. If you don’t have reasonable code in flash you need to disable the flash, power up the board, power up the raven. After the raven took control over the ARM, enable flash.
I had to replace the ribbon connector on mine as it gave me trouble right out of the box.
after you connect ,try typing “reg” in the ocd window. seee if you can see/change internal registers. Disable flash, then repower the board and try again
On the Net+50 development board there is a switch to break the OE~ line between the Net+50 and the flash part. 1) disable flash OE~ 2) establish jtag connection 3) enable flash OE~ 4) download application
How do you program flash if you can’t run out of RAM ? do you use custom hardware or netsilicon’s Dev. board ?
We use the jtag connection on the NetSilicon Dev Board.
If you are using your own hardware, without valid code in Flash, it may be that the raven is not getting control of the Arm. If there is no code in flash, or the flash is disabled and the data lines all float to high, then the Arm will execute code which prevents the raven getting control. We have found that at least one data line needs to be pulled down (e.g. D23 pulled to gnd with a 10k resistor on the Net50) to allow us to get control from the raven. We can then load and run code in ram, enable the flash, and then program the flash. We use a single 16 bit wide flash.
What kind of flash are you using? I’ve tried it with a AMD 29LV160 and a 1k pull down. I didn’t get D28 low enough to read a zero on this data line and therefore I couldn’t connect with the raven. It seems like the drivers in this flash chip are to strong. I can only connect to the raven with a short circuit on the data line, but this cannot be good for the flash.
Yes- and see the JTAG app note I found at:http://www.netsilicon.com/pdf/JTAG_solution.pdf
You need to disable the flash first! We brought out a spare chip select line from the AM29LV320 to the JTAG connector, so that we can disable the flash automatically in production. With the flash disabled, a pull down of 10k is easily low enough in value.
That’s right, with the disabled flash i can use a 10k. But i didn’t want to have too many additional parts on the production units to break up the chip select. What do you mean by spare chip select line? BTW, the thing i don’t understand is, why can i always connect with the old EmbeddedICE from ARM to my target, and the raven can’t do that?
I don’t know about the flash chip you are using, but I expect it is similar to the LV320, which has CE, OE and WE. Pull down *CE on the board, and put the signal on the programming connector to allow the flash to be disabled by your production programmer. *CE is not used elsewhere. In normal operation, *CE is permanently low, leaving the flash chip enabled. *OE and *WE are driven by the Net50 CS0OE and CS0WE respectively. These signals already have the address decoding and read/write decoding done in the Net50, so connect them directly to the flash. That’s it! The flash interface is glueless, unlike the SDRAM :-< I don’t know for sure why the Raven is poor at getting control compared to other devices, but I guess its not halting the processor immediately on release of the reset line.
Thanks for the hint. In our current design we are using the CS0, OE and WE signals and not the CS0WE and CS0OE. Maybe we can change it for the next one.
Has anyone actually made any experiences with the solution described in the JTAG_solution.pdf document? Does it really solve the problems mentioned in this discussion? It just seems to be the real solution of the problem instead of being just a work-around like the disabling of the flash and pulling D28 low. But does it really work?
Downloading the naftpapp software to RAM in my Netsilicon development board would not work anymore after the flash was messed up while debugging an unfriendly application in ROM. I tried some of the solutions suggested, and a modified version of one of them worked. The proper power sequence fixes the problem, but in a different sequence than noted. The correct way is: First power up the RAVEN, then the BOARD. If the board is powered up first then it is already in la-la land before the raven has a chance to take control. If the raven is powered up first, it is ready to take control as soon as the board powers up. If you don’t have reasonable code in flash you need to disable the flash, power up the RAVEN, power up the BOARD. The debugger is then able to download the naftpapp to RAM. Then enable the flash.