NS7520 chip support.

Development Boards MicroMod
1

Hi,

Has anyone tried using OpenOCD with the Digi Connect Wi-EM/Wi-ME module?

This module uses the NetSilicon NS7520 chip which uses the arm7tdmi

architecture. The data sheet is [here.

Update: here’s the full [reference manual. More doc’s can be found at Digi’s [website

The NetSilicon chip runs in big endian mode.

When I try to upload an image into ram via gdb, i get lots of these errors:

Debug:   embeddedice.c:153 embeddedice_read_reg_w_check(): 1
Warning: jtag.c:981 jtag_read_buffer(): value captured during scan didn't pass the requested check: captured: 0e check_value: 01 check_mask: 0f
Warning: jtag.c:981 jtag_read_buffer(): value captured during scan didn't pass the requested check: captured: 0f check_value: 01 check_mask: 0f
Warning: jtag.c:981 jtag_read_buffer(): value captured during scan didn't pass the requested check: captured: 0d check_value: 01 check_mask: 0f
Warning: jtag.c:981 jtag_read_buffer(): value captured during scan didn't pass the requested check: captured: 06 check_value: 01 check_mask: 0f
Debug:   embeddedice.c:153 embeddedice_read_reg_w_check(): 1
Debug:   embeddedice.c:153 embeddedice_read_reg_w_check(): 1

I believe that I ported the gdbinit script from the raven sample to openocd in order to initialize the chip…

Thanks,

luis…

ps: this is running under XP w/ OpenOCD v77](http://www.digi.com/products/embeddedsolutions/ns7520docs.jsp)](http://ftp1.digi.com/support/documentation/90000353_c.pdf)](Digi International Obsolete Product Information)

2

OpenOCD is likely to fail with bigendian targets (and hosts…). I don’t have access to a BE system, nor has anyone ever sent me some logs.

The warnings actually mean that there’s a severe problem with the JTAG communication. Could you recompile OpenOCD with DEBUG_JTAG_IO enabled in jtag.h, and send me the resulting log (-l <log.file>), together with the exact config file and .gdbinit script you’ve used?

Unfortunately I wont be able to work until before the end of next week, as I’m going on a short vacation after my last exam on wednesday.

Regards,

Dominic

3

This is not good news for me as I work on Net Silicon products and I would like to use OpenOCD.

Chips like the Netsilicon ones are much harder to get running via a JTAG debugger too as you tend to have to configure internal registers before you can debug.

These are Registers for things like the Memory Controller.

Until this Big Endian problem is solved you will have to use OCDemon or the Majic.

The Raven does not work too bad, but it is not very speedy (faster than a Wiggler of course).

I think the best way to proceed would be to get Big Endian working on a Microcontroller first and then look at bigger chips with external memory later.

This endianess thing is all a bit of a pain. The Internet is Big Endian (Motorola) and most of the computers in the world are Little Endian (Intel).

I prefer Big Endian (Mototola) myself as it is much more human readable in a memory window.

4

fordp:
This is not good news for me as I work on Net Silicon products and I would like to use OpenOCD.

Chips like the Netsilicon ones are much harder to get running via a JTAG debugger too as you tend to have to configure internal registers before you can debug.

These are Registers for things like the Memory Controller.

I know what you mean. I read the processor docs and looked at the supplied gdbinit.* files and other sample config files. Quite a bit of setup is needed to get it going.

I wish Digi had boot code which would setup most of those registers until the application starts up with the real values. Something along the lines that the LPC does.

Until this Big Endian problem is solved you will have to use OCDemon or the Majic.

The Raven does not work too bad, but it is not very speedy (faster than a Wiggler of course).

Unfortunately, I only have the Amontec JTAGKey. I really don't want to buy Yet Another JTAG...

I think the best way to proceed would be to get Big Endian working on a Microcontroller first and then look at bigger chips with external memory later.

This endianess thing is all a bit of a pain. The Internet is Big Endian (Motorola) and most of the computers in the world are Little Endian (Intel).

I prefer Big Endian (Mototola) myself as it is much more human readable in a memory window.

I've been working on the big endian MIPS platform with VxWorks for over six years, this little endian stuff throwis me for a loop!

At this moment, I stuck on developing on the Digi Wi-EM. I didn’t know that the boot rom or sample code do not allow you to upload new code. Good thing I have other coding that I could do.

luis…

5

Hello Luis,

thank your for sending me your log file. Your problems are not (only) because of your target’s endianness, but because of the JTAG communication (and probably your big-endian host, or did you run your GDB session on a different machine?). The JTAG communication bails out early, even the first captured value is bogus:

Debug: jtag.c:926 jtag_build_buffer(): fields[0].out_value: 3f

Debug: jtag.c:957 jtag_read_buffer(): fields[0].in_value: 3d

the in_value should be 0x31 (b110001), as the chain validation shifted in 6 bits (b111111), and the device should load b0001 into its IR register. Your jtag_speed value is already 40, further raising this probably wont help.

I’ve just checked the chip’s user’s manual, and it shows that the PLLTST bin has to be tied high to enable ARM debugging, otherwise the boundary scan TAP controller is enabled - or maybe the other way round (page 51):

The PLLTST input is connected to ground to use the JTAG debugger. It is connected to 3.3 volts through a 10K resistor to use boundary scan testing.

Tie high to use the JTAG debugger Connect to ground to use boundary scan testing

Only ARMs are guaranteed to load b0001 into their instruction register - other implementations are free to do something else, like loading b1101 - the standard only requires the two LSB to be b01.

Maybe you can check your setting of PLLTST, and maybe invert it if possible. You can verify that the device is in boundary scan mode by removing the ‘target …’ line from the config file, and changing the jtag_device line to

jtag_device 16 0x01 0x03 0xfe

If you’re able to launch the OpenOCD with this setting, it’s verified that the connected device has a IR scan chain of at least 16 bit. The 4-bit configuration only passed the test as the other bits coincidentially matched the expected pattern.

Regards,

Dominic

6

Thanks for the investigation, Dominic!

I’ve updated the code to v78. Also, I’m running openocd on Windows XP.

Dominic:
[snip]

I’ve just checked the chip’s user’s manual, and it shows that the PLLTST bin has to be tied high to enable ARM debugging, otherwise the boundary scan TAP controller is enabled - or maybe the other way round (page 51):

The PLLTST input is connected to ground to use the JTAG debugger. It is connected to 3.3 volts through a 10K resistor to use boundary scan testing.

Tie high to use the JTAG debugger Connect to ground to use boundary scan testing

'k...I'll look into this...

Only ARMs are guaranteed to load b0001 into their instruction register - other implementations are free to do something else, like loading b1101 - the standard only requires the two LSB to be b01.

Maybe you can check your setting of PLLTST, and maybe invert it if possible. You can verify that the device is in boundary scan mode by removing the ‘target …’ line from the config file, and changing the jtag_device line to

jtag_device 16 0x01 0x03 0xfe

If you’re able to launch the OpenOCD with this setting [snip…]

Hmmm…openocd doesn’t like not having a target 0 configuration…

7

Hmmm…openocd doesn’t like not having a target 0 configuration…

Last time I checked, it did. I use it to program my Amontec Chameleon dongle, and to test with new devices. What happens if you remove the target line, and try to run the OpenOCD? Removing working_area, flash and other target-specific commands might be necessary, too.

Regards,

Dominic

8

'k got it. removed the other target specific settings.

This is what I get:

$ openocd/trunk/src/openocd.exe -d3 -f d.cfg
Info:    openocd.c:82 main(): Open On-Chip Debugger (2006-07-15 12:00 CEST)
Debug:   jtag.c:1150 jtag_init():
Debug:   ftd2xx.c:887 ftd2xx_init(): current latency timer: 2
Debug:   ftd2xx.c:977 jtagkey_init(): 80 08 1b
Debug:   ftd2xx.c:1034 jtagkey_init(): 82 09 0f
Debug:   ftd2xx.c:143 ftd2xx_speed(): 86 14 00
Debug:   jtag.c:234 jtag_call_event_callbacks(): jtag event: 1
Debug:   jtag.c:1044 jtag_reset_callback():
Debug:   ftd2xx.c:735 ftd2xx_execute_queue(): statemove: 0
Debug:   jtag.c:234 jtag_call_event_callbacks(): jtag event: 1
Debug:   jtag.c:1044 jtag_reset_callback():
Debug:   jtag.c:931 jtag_build_buffer(): fields[0].out_value: 03ffff
Debug:   ftd2xx.c:773 ftd2xx_execute_queue(): IR scan, 18 bit, end in 0
Debug:   jtag.c:962 jtag_read_buffer(): fields[0].in_value: 00f7f7
Error:   jtag.c:1096 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch

$ openocd/trunk/src/openocd.exe -d3 -f d.cfg
Info:    openocd.c:82 main(): Open On-Chip Debugger (2006-07-15 12:00 CEST)
Debug:   jtag.c:1150 jtag_init():
Debug:   ftd2xx.c:887 ftd2xx_init(): current latency timer: 2
Debug:   ftd2xx.c:977 jtagkey_init(): 80 08 1b
Debug:   ftd2xx.c:1034 jtagkey_init(): 82 09 0f
Debug:   ftd2xx.c:143 ftd2xx_speed(): 86 14 00
Debug:   jtag.c:234 jtag_call_event_callbacks(): jtag event: 1
Debug:   jtag.c:1044 jtag_reset_callback():
Debug:   ftd2xx.c:735 ftd2xx_execute_queue(): statemove: 0
Debug:   jtag.c:234 jtag_call_event_callbacks(): jtag event: 1
Debug:   jtag.c:1044 jtag_reset_callback():
Debug:   jtag.c:931 jtag_build_buffer(): fields[0].out_value: 03ffff
Debug:   ftd2xx.c:773 ftd2xx_execute_queue(): IR scan, 18 bit, end in 0
Debug:   jtag.c:962 jtag_read_buffer(): fields[0].in_value: 03febd
Debug:   openocd.c:98 main(): jtag init complete
Debug:   openocd.c:102 main(): target init complete
Debug:   openocd.c:106 main(): flash init complete
Warning: gdb_server.c:1072 gdb_init(): no gdb ports allocated as no target has been specified
9

I have no idea why the first run failed, but the second run suggests that the boundary scan TAP is used:

0x3febd (b…10111101) matches the 0x3d scanned out when you used the config file for the ARM7 (4 bit IR register).

The 0x00f7f7 captured in the first run on the other hand make no sense at all. Is this a board you’ve developed yourself, or is it an evaluation board, i.e. is the JTAG port known to work?

Regards,

Dominic

10

Dominic,

The board I am using is the Digi Wi-EM development kit.

As you said, there is no mention in any of how to pull the PLLTST pin high. Since I have been in discussion with the Support Wizards at Digi, I’ve sent an email to aid in figuring out this dilemma. a link to this forum was also sent.

Hopefull, they joing this discussion.

I’m going to try an track down the schematics to the development board to see if the pin is brought out.

…

The first run that you is what I get quite a bit. I have to rerun openocd a number of times before it hangs onto the processor. Sometimes, openocd just quits because of some error.

[snip]
Debug:   jtag.c:962 jtag_read_buffer(): fields[1].in_value: a7f086eb
Debug:   jtag.c:962 jtag_read_buffer(): fields[1].in_value: 0390320a
Error:   armv4_5.c:186 armv4_5_mode_to_number(): invalid mode value encountered
Debug:   arm7_9_common.c:926 arm7_9_debug_entry(): target entered debug state in Jazelle mode
Error:   armv4_5.c:186 armv4_5_mode_to_number(): invalid mode value encountered
Error:   arm7_9_common.c:931 arm7_9_debug_entry(): cpsr contains invalid mode value - communication failure
Error:   target.c:1006 handle_target(): couldn't poll target, exiting
$

but this may be because the chip is not the right JTAG state(???)

luis…

11

but this may be because the chip is not the right JTAG state(???)

Exactly. The values captured just match out of coincidence, but actually not a single bit of “debug data” was transmitted.

Warning: jtag.c:981 jtag_read_buffer(): value captured during scan didn’t pass the requested check: captured: 0e check_value: 01 check_mask: 0f

Whenever you see one of these lines, the JTAG communication is seriously flawed, and everything in the log file after that is bogus.

Regards, Dominic

12

well…got a reply from the Senior Support Engineer at Digi, here’s the pertinent part of his reply:

The PLLTST line is not made externally accessible to you, on the Connect modules. It is, however, pulled high, internally.

Since the it is pulled high, I'm wondering why it is not working.

Sigh…I’m spinning my wheels at the moment, so i looks like i might have to buy another jtag for this chip.

I do REALLY want to get off of the windows platform and do the debugging on my Mac. And I will still help you in getting OpenOCD to be endian independent of target and host. Just let me know what tests you want run, and i’ll send you the logs.

Thanks for the help Dominic!

luis…

13

Hello Luis,

thanks. I’ll get back to you when I’ve returned from my vacation, probably thursday/friday next week. As my exams are over, I’ll have a lot more time to work on the OpenOCD, and I’m sure we can get your problems solved.

Best regards,

Dominic

14

Hi Dominic,

Just checking to see if you have made any progress in

the big endian side of things. I do notice that a number

of checkins have occurred.

Thanks,

luis…

15

Hello luis,

sorry I didn’t reply to you earlier.

I’ve gone through most of the code, and the big-endian stuff (target wise) shouldn’t be too hard. After all, endianness is about the memory system, and the OpenOCD should be able to live with whatever the target provides. At least basic functionality like halt, resume, register access etc. should work.

Unfortunately, you’re the only one that approached me with a big-endian target, and there seem to be other problems with the chip you’re using, even low-level JTAG communication is broken.

I’ll look into the NS7520 manuals again tomorrow, maybe there’s something I missed about its JTAG interface.

Regards,

Dominic

16

I think you should test your setup with OCDemon first. Your JTAG interface should be able to emulate a RAVEN and so should work.

NetSilicon even provide all the turorials for the OCDemon/ Raven combination.

Check your documentation to find out how to get your interface into Raven mode.

Once that is working you can try OpenOCD again.

Good Luck!