02-01-2019 11:24 AM
Using the NAT9914 with a PIC18F47J53.
We to take control and become a CIC, but when we call the aux command to clear the IFC (100us after asserting it), the IFC line goes inactive as expected but the state machine does not enter the StandyBy State, it goes to Idle. The ISR2.CIC and ADSR.ATN bits are both clear (0).
We follow the documentation and other examples we’re seen for NAT9914 initialization.
We can run all the Test.c test routines (from AN110) successfully.
Any Clues?
Chad
The Init routine
void GPIBInit(void)
{
// now initialize the 9914
PORTBbits.RB2 = 0; // reset line for 9914 - line pulled high, force low
Delay10TCYx(20);
PORTBbits.RB2 = 1; // reset line for 9914 - line pulled high, force low
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_ch_rst); // goes to PON
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_swrst); // goes to operational
// now we have to set the clock divisors. Since we have to set the MICR bit, we have to go to 7210 mode
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_sw7210); // now 7210 mode
gpibRegWrite(NAT9914reg_AUXCR, 0x50); // 7210 page-in of ICR2 (7210-mode only register)
gpibRegWrite(3, 0x81); // sets the MICR bit
gpibRegWrite(5, 0x15); // sets the chip back to 9914 mode
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_piaccr); // page-in for hidden reg
// (0x20 accesses the ICR) target is a 1MHz internal clock. 12 MHz from me, MICR set divides by 2 = // 6MHz, then divide by 6 to get 1 MHz
gpibRegWrite(NAT9914reg_ACCR, 0x20 | 6); // hidden ACCRA
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_clrpi); // page-out
gpibRegWrite(NAT9914reg_ADR, 0); // @@@will change to set address later
gpibRegWrite(NAT9914reg_SPMR, 0); //@@@4); // parallel poll not supported on first -00 HW
gpibRegWrite(NAT9914reg_IMR0, 0); // not using interrupts, all polled
gpibRegWrite(NAT9914reg_IMR1, 0);
gpibRegWrite(NAT9914reg_IMR2, 0);
// Set T1 delay default of 2us
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_vstd1N); //
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_std1N); //
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_piaccr); //
gpibRegWrite(NAT9914reg_ACCR, 0xE0); // hidden ACCRI
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_clrpi); // page-out
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_swrstN); // goes to operational
if(GPIB_IAmSystemController) gpibControllerBecome();
}
The Take Control routine.
static unsigned char gpibControllerBecome(void)
{
unsigned char rr = 0;
// we will not listen when controller for now.
// we will also not allow taking control automatically for now (we'd need to do more work)
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_piaccr); // page-in
gpibRegWrite(NAT9914reg_ACCR, 0xA5); // ACCRB features LWC | ATCT
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_clrpi);
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_sic);
Delay100TCYx(24); // delay 200 us [100us is required] (2400 instructions - 2400/12e6=2e-4)
getCIC();
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_sicN); //@@@ doesn’t go to Standby State, CIC = 0, goes to Idle.
getCIC();
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_sreN);
getCIC();
Delay100TCYx(24); // delay 200 us [100us is required] (2400 instructions - 2400/12e6=2e-4)
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_sre);
getCIC();
gpibRegWrite(NAT9914reg_AUXCR, NAT9914AUXCR_gts);
getCIC();
rr = gpibRegRead(NAT9914reg_ISR0); // check BO is set
gpibIsSysController = 1;
gpibTalkerLast = 0xfe;
gpibListenerLast = 0xfe;
return 0;
}
02-04-2019 05:06 PM
Hey Chad,
Thanks for posting your question on our forums. I'd like to better understand the issue you're seeing:
1. Do you have a link to the example code / documentation that you're using for the NAT9914 initalization. Also, i'ts unclear what the Test.c test routines that you're referring to are.
2. What programming language are you coding in? What IDE? This looks like C to me. Are you using LabWindows/CVI?
3. Are you able to see your devices in NI MAX?
4. What is the application of this project? What are you trying to achieve?
Thanks,
Ben
02-04-2019 05:48 PM
Hi Ben,
The app note 110 341398A-01 "Designing a GPIB Device Using the NAT9914" has useful sample code to verify you are indeed communicating with the NAT 9914 from the CPU point of view, no device attached. All these test run successfully.
Our CPU is Microchip PIC18F47J53, Here are Photon Kinetics we use this part everywhere, very useful micro. That being said we're using MPLAB IDE v8.92 and the C18 compiler version 3.47. We are using the 75160 and 75161 buffers. And yes the data bus MSB-LSB is upside down.
Not using LabWindows/CVI. We are very conversant with GPIB and the NI libraries.
The application is a USB to GPIB adapter for PK embedded product.
The issue is in taking control, we become a CIC (Aux Command sic) , toggle the IFC line (100us pulse) and then attempt to Go To Standby (Aux Command gts) , however the CONT* line is become un-asserted when the IFC line is released. For some reason we don't understand yet, we cannot get into the Standby Controller state, we transition to Idle Controller instead.
From NAT9914 Reference Manual 7-1...
CONT* (or equivalently CIC*) asserts when the NAT9914 is the Active or Standby
Controller. CONT* unasserts when the NAT9914 is an Idle Controller. The NAT9914 is
CIC when it is the Active or Standby Controller.
Referring to the IEEE 488.1 Controller function:
CONT* = CIDS + CADS
When the NAT9914 is the Active Controller, it asserts the IEEE 488 ATN* signal. As
the Active Controller, the NAT9914 can send remote multiline messages (commands)
and conduct serial and parallel polls.
When the NAT9914 is the Standby Controller, it does not assert the IEEE 488 ATN*
signal. When the NAT9914 is the Standby Controller, the IEEE 488 Addressed Talker
can send data messages to the Addressed Listener.
The value of the CIC signal can be read as bit ISR2[0]. If CIC = 1, the NAT9914 is
asserting the CONT* pin.
The NAT 9914 state machine transitions are not doing what we expect.
Chad
02-10-2019 08:02 PM
May check this document.
http://www.ni.com/pdf/manuals/371430a.pdf
"• Page 3-15, first paragraph, replace the existing text,
"Note: Writes to the AUXCR"
with this new text,
"Note: Any register access following a write to the AUXCR""
The key is
"Any access following a write to the AUXCR should be delayed by at least four clock cycles." <---Check by the oscilloscope.
It may solve this issue.
Good Luck!!
02-11-2019 11:11 AM
Four clock cycles, yes I saw that--assuming that is at a 1MHz clock rate.
Chad
02-11-2019 11:53 AM
We have plenty instruction delay between write accesses the AUXCR register on the NAT 9914.
We are using the 75160 and 75161 transceivers.
We attempt to become an Active System Controller and then go to Standby
write sic (ATN, IFC, CONT* asserted)
wait 100us
ISR2.CIC is 1
ADSR.ATN is 1
write ~sic (ATN, IFC, CONT* NOT asserted)
...and this is the problem with CONT* NOT asserted we can't be in Standby State.
ISR2.CIC is 0 and ADSR.ATN is 0
We're doing something wrong but we don't see it
02-12-2019 07:09 PM
Can now get the NAT 9914 into Active Standby State
Using AUXCR commands...
TakeControl()
{
sic (Set Interface Clear)
(delay 100us)
~sic (Clear Interface Clear)
rqc (Request Control)
gts (Go to Standby)
}