Need for help, N2HET SCI simulation

Zhong,

This could be due to many things,  so let's start by trying to narrow down the problem.

Can you please confirm some basics:

  1) is your N2HET program loaded into N2HET RAM?

  2) have you started the N2HET?  (Can you see the ADDR register of the N2HET changing? - this is an indication that the N2HET is started).

  3) how have you programed the N2HET registers, especially GlbCtrl, Pfr, DIR

  4) did you configure the pin muxing on the chip so that the pins you want to transmit on are controlled by the N2HET?

Now if you do see that your program has been copied into the N2HET, it's running the code, and the pinmux is correct, what do you see that makes you think that the code *is not* running correctly?

Anthony,

   Thanks for your quick feedback.

   The ARM main program is OK, I have used it for testing other N2HET programs. So for narrow down the problem.

1. N2HET is loaded by HALcogen code, initial by hetinit(). I have called it.

4. I do the Pin Mux as simple as possible to isolate other problem. The main program just used as N2HET testing. Only HET1/2 and SCI2/LIN Enabled. Theoretically, all HET pins are available. As I am using RM48 HDK. There are some HET pin connected to the LED. I can also check the program's status by visual.

3. I manually initial the GCR. For there is a trap. If you not initial one HET as MASTER, the N2HET program will NOT run.

2. I've tried both suspend or non-suspend mode. And checked the memory of N2HET program. The data field changed. And I can see the program logic is Ok by judging the binary data.

hetREG1->GCR = 0x01030001U;

hetREG1->GCR = 0x01010001U;

So what is my guessing. It is a little long story. Thanks for your patience for reading.

My program is quite strait forward.

TX1_INPUT   MOV32   { next=TX1_InChk, remote=TX1_Shift, type=IMTOREG&REM, reg=A, data=852 } ; NOTE: set by the main ARM program prior TX. If (Stopbit NOT Set 1) THEN stop sending 

By changing TX1_INPUT for data sending. If you send a all '0' in it, the program stop. As there is a programmed 852, it will send  01010101B constantly.

I have tested the N2HET program in HET IDE, the result as expected. But there is a QUESTION.

In application note, SPNA097, it used a weird way to SET / CLEAR the line.

TX1_Shift SHFT { next=TX1_LoadA, smode=IRZ, cond_addr=TX1_LoadA,
 cond=UNC, pin=DUMMY_PIN, reg=NONE, irq=OFF, data=0 }
; Load 0 to register A (Used as MCMP compare value)
TX1_LoadA MOV32 { next=TX1_CheckZ, remote=TX1_LoadA, type=IMTOREG,
 reg=A, data=0 }
; Test bit that was shifted into Z
TX1_CheckZ BR { next=TX1_Low, cond_addr=TX1_High, event=ZERO, irq=OFF }
; Set TX1_PIN
; The comparison with register A must always be true.
TX1_High MCMP { next=TX1_Reload, cond_addr=TX1_Reload, reg=A,
 en_pin_action=ON, pin=TX1_PIN, order=DATA_GE_REG,
 action=SET, data=0x7FFFF}
; Clear TX1_PIN
; The comparison with register A must always be true.
TX1_Low MCMP { next=TX1_Reload, cond_addr=TX1_Reload, reg=A,
 en_pin_action=ON, pin=TX1_PIN, order=DATA_GE_REG,
 action=CLEAR, data=0x7FFFF}

In short word, it used SHFT to shift a bit into Z flag and use MCMP instruction to Set/Clear the line. It is so weird:

• Why not use the SHFT to output to the PIN?
• Why not use PulseLo/Hi which can changed their behavior while Z flag captured.

There is another reference design

http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/229245/889281.aspx#889281

SCITX    CNT     { next= Lm10,  reg = T, max= 12, irq = OFF,data=0}
Lm10     BR      { next= SCIRX, cond_addr= Lm11, event = ZERO}
Lm11   DJZ { next=SendOverINT,cond_addr=SCIRX,reg=A,irq=OFF,data=0}; set to number of bit to transfer
SendOverINT   CNT { reg=A,irq=ON,max=9,data=0};
Lm12 SHFT { next=SCIRX,smode=OR0,prv=OFF,cond_addr=SCIRX,cond=UNC,pin=TX1_PIN,reg=A,irq=OFF,data=0x0};

I use the SHFT instruction as his way (Haixiao Weng). Shift out the LSB to HETx and Load 0 in MSB.

My testing result is:

1. As the TX pin pull up. I used a oscilloscope trigger by the falling edge of TX (the start bit)
2. The result is after hetREG1->GCR = 0x01030001U, the N2HET program running, the Line pull low and never pull up.
3. The SHFT instruction's data field changed and shifted as expected. But the Line status is not the way I wanted. 

Above all, my guessing is:

1. The SHFT instruction is NOT well documented in the SPNU503B the TRM. There is NO execute program/logic documented. We can not know what exactly it done.
2. As there is two way of implementation for SHIFT and output to LINE. I may think, is there any difference in NHET and N2HET. so make the two program look difference. 
3. Or there is some trick, the SPNA097 just worked around the SHFT problem.

So, would you please run the N2HET program in HET IDE for replicate the result of mine. And test it with RM48 HDK to check if it worked. 

It would be NICE to provide detail execution logic of SHFT instruction. I need to know whether I can use SHFT as LINE Input/Output operation. Or just use it as an ALU operation.

Thanks anyway!

Since my name is mentioned here, and my old post is forbidden to be read even by me, I am going to post my solution for N2HET emulated SCI.

7485.N2HET_EMU_I2C.ZIP

4505.N2HET_EMU_I2C_AppNote.pdf

Regards,

Haixiao

Sorry, upload the wrong files.

8117.HET_EMU_SCI.ZIP

4186.N2HET_EMU_SCI_AppNote.pdf

Haixiao

Dear Hai Xiao,

  It's very glad to hear you. It's your program to make me decide to write UART for the N2HET.

  I've checked your newer version of program. It well commented and there's application not for understanding the high level logic flow. (It take me time to understand your old one without comment)

  As my need, I will use the N2HET/SCI for some fixed length data send/receive. It quite important to offload CPU from polling the devices. I want to use DMA / HTU to accomplish this tasks.

  For there is no sync mechanism for communication between ARM & N2HET. Checked your program,

void HetUART1PutChar(char Data)
{
  unsigned int Tmp = Data;

  Tmp <<= 1;                                    // Shift in start bit (0)
  Tmp |= 0x00000200;                            // Add stop bit (1)
  while(hetRAM1->Instruction[2].Data != 0);
  hetRAM1->Instruction[4].Data = Tmp << 7;  // Load TX buffer
  hetRAM1->Instruction[2].Data =  10 << 7;  // Load bit count
}

  The ARM CPU need to poll & wait byte to shift out.  So I've base on your application & the old application note to write my own version. Your program is great, you give a quite kickstart.

  My pain point is:

      Would you please check my program if it used the SHFT instruction correctly. And I get the correct result in HET IDE, but no luck in RM48HDK. (RM48L952 board no USB version)

      Since I did not work with the simplest part of the SCI, the TX. Please give me a hand. I think I will follow your design for the RX. It dame sure robust for noise immunity. 

      Thanks!

I did not see anything wrong.

Can you please upload your CCS project and the UART settings (baudrate, stop bits, parity)?

Thanks,

Haixiao

Dear Haixiao,

4062.UART_test.zip

   This baudrate is not a matter.  If the program can generate wave form, I think I can tweak  it later.

   The UART setting is 8 data bits, 1 stop bit, no parity. As there may different clock setting,  I am using  the parameters below. 

BIT_PRD .equ 162 ; 1 bit period [LRCLK] less 1
BIT_PRD_1_5 .equ 241 ; 1.5 bit period [LRCLK] less 1

   Thanks!

I can not unzip the file.

Haixiao

Re upload it.

6232.UART_test.zip

Hi,

void main(void)
{
/* USER CODE BEGIN (3) */
	uint32_t	tx;
	uint32_t	rx;

	sciInit();
	hetInit();
	hetREG1->GCR = 0x01030000U;
	hetREG1->DOUT = 0xFFFFFFFF;
	hetREG1->DIR = 0xFFFFFFFF;

	hetREG1->INTENAC = 0xFFFFFFFF;
	hetREG1->FLG = 0xFFFFFFFF;
	hetREG1->GCR = 0x01030001U;

I have use this program to test other N2HET programs.

As you mentioned, I initialized the HET I/O direction at main().

Dear Hai Xiao,

   Thanks for your patience. The problem was cause by tricky n2het-disable function. 

   You pointed out a potential issue in my program. It is a valuable suggestion. (HR_LR=LOW)

   And, I wrote a UART TX/RX program based on your majority vote methodology. Added some IRQ / DMAreq function. It works great and robust. It avoid the misalignment problem.

   I found that, it would NOT be easy to use higher baud rate than 115200. eg. 230400 or higher.

  Any suggestion?

True.

As frequency goes higher, the number of instructions per LRP is limited (as a result of using a high frequency LRP). The only thing you can do is to optimize the number of instructions.

For the UART, 230400 is feasible for one channel, may be two channel.

Regards,

Haixiao

Haixiao,

the pdf and zip for the i2c simulator do not contain the .het source file. Any chance that it's still available somewhere?

edit: the zip file attached here does, the one I opened from http://processors.wiki.ti.com/index.php/RM46_CNCD doesn't.

Hi Jan,

Haixiao has left us, so I'll respond as best I can.  The folder  ...N2HET_EMU_I2C\source\HET_EMU_I2C appears to have the HET IDE project in it for I2C.  The source is the .het file.  Haven't tried out what Haixiao did myself but let us know how it works.

Yes, I found it now.

I managed to port the n2het/i2c emulator part to the Hercules LaunchPad with TMS570LS04x (I can't port the whole example because it connects the i2c to a physical i2c peripheral in the Hercules, and my versiuon doesn't have that module).

I don't have it working yet, but I managed to eek out the i2c start sequence out of it :)

Thanks for the pointer to the  .het. source.

It's getting better; Result of the Hercules LaunchPad talking to a TI FuelTank Boosterpack via the N2HET emulator