I was wondering if it is possible to have two [or more] ULINK devices running on the same PC ?
I 'expect' [hope] to be able to launch two Keil IDE's and run two Target Boards using two ULINK devices.
Is that possible?
Ref: http://www.keil.com/forum/docs/thread6385.asp (Noting that it went un-answered, and it is really old)
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Tamir & Per: Thanks for the good info about NSS/SSEL lines.
Per, I do realize those issues, but when the data-sheets say Hardware Controlled, then I'd expect it to be just that at least on a per-byte basis.
They shouldn't advertize Hardware Control if it doesn't do that.
And like PWM A/B signals, dead-time controls could be put into the fabric (ref#3).
In cases of #2, I would expect it to be software controlled.
Case #1 is simply some glue logic to chip-select which slave to address, and NSS/SSEL the enable (or AND gates) for each slave. ...which is what I had expected to do.
I'm not shooting holes in your logic, its just that your conclusion might be valid (So it is quite complex), but it is definately possible and fairly easy to do in an FPGA/VHDL to address my "counter-points."
At this point, we are most likely going to move the SPI bus into the FPGA to handle everything as we would like it, and simply memory map the data I/O. (We need speed).
Again, thanks for the information. I'll definately keep your points in mind when we do move it into the FPGA.
I have discussed this before. It isn't so easy to have generic hw-acceleration for driving SSEL signals.
1 - one master may have multiple slaves, and hence a need for driving multiple SSEL lines in random combinations.
2 - some protocols sends one byte/word at a time, with SSEL toggled in between. Some protocols sends large messages (possibly several reloads of the FIFO or significant DMA bursts) between each SSEL change.
3 - some slaves have very specific requirements for settle and hold times for SSEL, potentially requiring a number of bit times between each transfer.
So it is quite complex to create a programmable solution for hw-driven master-side SSEL.
The NXP LPC23xx (and I'm pretty sure the LPC17xx) requires the master to drive the SSEL manually. This is very common behaviour even for very advanced SPI implementations with FIFO, DMA etc.
Captain,
You posted
The [current] problem is that the NSS signal is not hardware controlled (no matter how much the data-sheets and emails to/from STMicro say otherwise)
Just for your information, this is also required on a LPC2468/78. Here is a question I posted several months ago to NXP, and the reply. As far as I could see it is not indicated in the user manual, but I might have missed it. This behavior makes a lot of sense, actually... I hope this can help you too:
Dear Madam/Sir,
We are reading the measurements of an external ADC connected to a SPI bus. We have noted that even though the LPC2478 is configured as having P0.16 with the role "SSEL (SPI), the chip select is not generated upon data transmission (we act as the bus master, of course). We are forced to manually clear and set P0.16 to correctly address the ADC. Is this a know issue? What can be the cause of this?
Kind regards,
Tamir Michael --------------------------------------------------------------------------- NXP Semiconductors answer: Hello Tamir,
Yes, this is the way it works. SSEL is only used in slave mode. As a master you need to control the slave's select pin in software using a GPIO pin.
Regards, Paul
Thanks guys!
product(s) are almost done...!
Tamir, let me 'almost' congratulate you then ;-). It is indeed a good feeling to get something done after tons of work go into it... and I'm sure you've put many man-hours into those product(s).
In the future, we'll probably mainly use Cortex based chips, but first NXP have to release the Cortex M3
I too prefer the Cortex M-3 chips. I've stuck with STMicro's line so far, but NXP might be next on the hit-list.
I'm running SPI to multiple processors and using the SMT32 series as the master.
The [current] problem is that the NSS signal is not hardware controlled (no matter how much the data-sheets and emails to/from STMicro say otherwise). So I have to bit-twiddle the NSS line. I might be looking for a different Cortex M-3 variant.
[Note: I just put in a requisition for a new STM3210-EVAL board, and maybe a 'new' board will control the NSS signal in hardware].
I CAN CONFIRM, that 2 ULINKS work at the same PC without problems. (got one for ARM7 and one for CM3)
only difference is that you have to tell uV, which one to use
regards
The problems I mentioned are strange, and apply only to design surrounding the LPC2478 chip - a similar one that uses a LPC1768 has no problems at all. It must be a routing problem of some kind (it has nothing to do with the double chip design - it happens on another product using a single chip) - often, if a program is stepped through control is lost - it can also happen if the debugger is started. It is very disturbing, but related directly to our hardware. The good news is that the product(s) are almost done...! No setting in uv4 seems to alleviate the situation. In the future, we'll probably mainly use Cortex based chips, but first NXP have to release the Cortex M3 equivalent of the LPC2478 (LCD controller)...!
I think there's some ambiguity as to whether you're using "drivers" in the hardware or software sense there...
Since my origional post, I've had to drive down to the Department of Motor Vehicles, twice: 13 miles each way in traffic.
Hence my long durations between posts. TWICE !! (Both of those were because of the STUPID DMV People not getting their ducks in a row: my wife had to sit there for three hours, and I needed to sign two documents--of which I had previously been to the DMV to sign a bunch of documents before! Oh, yeah... and here's another one--drive down. Ah, another! drive back)
Anywho, I usually suspect the USB drivers that are sold as add-on cards to a PC. I've seen some that don't/won't handle the 500mA requirement: I've reversed engineered the devices (e.g. looked at the parts) and it turns out that they cannot supply 500mA at all.
With such flakey electronics, it wouldn't surprise me if these cards had flakey drivers.
But, Andy, your point is well taken.
P.S. Oh, I can hardly wait for Obambi-Care to kick in. </rant>
I had problems using just one uLink on my Toshiba SatellitePro laptop: http://www.keil.com/forum/docs/thread14502.asp
I remain unconvinced as to whether it was the PC or the uLink (or its drivers) at fault...
Tech support said it would work...
"Yes. it will work. If you plug in 2 ulink2s to your computer, open Keil and go to
project > options for target > debug > use: 'ULINK ARM debugger"
and click the 'settings' button
Under the serial number, the serial numbers of each ULINK2 will show up here. Make sure to keep track of which ULINK2 SN you have hooked up to each board.
Set this session of Keil to use one ULINK2, and then open a new session and set that one to use the other ULINK2. Depending on your USB chipset on your PC, when you connect, you may have try a couple times, but it will work."
(I'm sure that not all of the customer base has decent computers with 'real' USB chipsets in them, so I think that is what was meant by 'try a couple of times')
I just thought I'd close the thread out with the resolution for all of us.
P.S. Erik... nice: debugging seven controllers at once!
Does that mean you have 7 Keil IDE's running at the same time too? nope, since SILabs and Keil are constantly out of synch, I run them separately.
Erik
Erik,
You said SEVEN SiLabs units running at the same time? Does that mean you have 7 Keil IDE's running at the same time too? (I've run one IDE using the ULINK and had another IDE simulating another processor at the same time before).
Sweet.
But you did say you had problems. What kind of problems? Rare? Constant? Work-arounds? etc?
Yes that is correct: 2 uv4 IDE's running on one PC, while 2 physical ULINK2s are connected to that PC.
Tamir, I hope you mean two ULINKs and not onE ULINK chained to two targets. (?)
View all questions in Keil forum