Hi there! I am about to bring up our own hardware with NET50. I already can read the registers of the NET50 via the reg command. But I can’t access the NET50’s internal memory, e.g. the Chip Select Registers. From the read command (memread 4 0xffc00010) I get a result but the result makes absolutely no sense and differs with every read. I have no idea where this data comes from… Any ideas? I’d preciate every hint. -Stefan PS: I use GHS 3.61 and the Raven.
Some things to check: 1) Your JTAG interface circuitry needs to exactly match the recommendations in the latest datasheet… Any deviations can cause many problems as the NET+50 isn’t very tolerant w.r.t the JTAG port… Pay special attention to the pullup resistors 2) I know from bitter experience that the JTAG interface, Raven and the GNU tools only work in Big Endian mode… If you are using LE mode perhaps the problem also exists with the GHS tools? 3) Your parallel port needs to be configured in the bios for the correct mode… EPP I think… Check the documentation for the tools. 4) Have you tried downloading OCDcommander from www.ocdemon.com to see if this is more reliable for investigating the special function registers? 5) Have you looked for driver/software updates for the GHS tools?
Well, I had a few mistakes on my board, including a short-circuit on the data bus. And I replaced and added many capacitors and that helped. I realised the Net+50 is very sensitive regarding the selection and the right placement of the power supply capacitors. So now most of the times the system works. Anyway I have still sometimes problems to access the internal registers (like described above). But: these problems come and go. After one day of successful working, I want to start the other day and the system won’t work, that’s not fun!
But… I thought my OCD connection is working well, as I can read/write the ARM’s registers.
>But… I thought my OCD connection is working well, as I can read/write the ARM’s registers You would think so… but past bad experiences have led me to be more cautious regarding of the debug tools 
BTW When attempt to read/write the SFRs have you halted the core and setup register 0xffb00000 first? The following is an extract from my GNU (insight) ini file… not strictly relevant but does show the order that the SFR’s need to be setup in… # # setup SFRs # monitor long 0xffb00000 = 0x4004a000 # # SDRAM Burst Termination GPIO setup # monitor long 0xffa00000 = 0x00001000 monitor long 0xffa00040 = 0x00800000 monitor long 0xffa00044 = 0x00800000 # # Memory controller setup # monitor long 0xffb00030 = 0x00000000 monitor long 0xffc00034 = 0x00000f04 monitor long 0xffc00030 = 0x00000001 monitor long 0xffc00010 = 0x0 monitor long 0xffc00000 = 0x0dc00000 monitor long 0xffc00024 = 0xfc000070 monitor long 0xffc00020 = 0x0000022d monitor long 0xffc00014 = 0xFF800404 monitor long 0xffc00018 = 0x00000000 monitor long 0xffc00010 = 0x04000003 monitor long 0xffc00030 = 0x0 monitor long 0xffc00034 = 0x0 monitor long 0xffb00008 = 0x09000e1e Also you need to remember the SFR must be accessed in aligned 32-bit access… If you use byte or half word reads/writes the core will data abort which causes the core to start running and jump to the data abort exception handler… which probably wont exist! This leads to unreliable read/writes of the SFRs via the JTAG I/F I also remember some previous posts on one of the tools list that talked about problem with ICE I/F… The solution as far a I can remember involved using OCD commander to setup the memory controller… closing OCD commander… then starting up the proper debugger… You might try searching either the GHS tools or GNU tools list for the original posts… Regards Dave