Tidu794 Biss C app note question

Hi Bob,

Thanks for finding this - this seems to be a mistake in the board design. As you suggested, please connect the mcasp0_aclkx signal to the "R" output of the receiver (U57, pin 1) via a blue wire. R428 and R427 should not be populated if the blue wire workaround is used.

We will update the documentation.

Regards,

 Thomas

Hi Thomas, Thank you. Should I also remove R14 or is pin MMC0_DAT2 configured as an input?

Should be R514 not R14.
Also, how was this code tested if that change was missed on your side?
Thanks,
Bob

Also, on page 31 of the app note it says to select the initialization script, but the name of the script is cut off in the box on the right. Which initialization script should be used?

Hi,

may I have the same problem with an AM437X IDK board ?

I'm trying to get the TI-Design "BISS-C-Interface Master" tidu794 running. The code stops every-time with the error "NO_SLAVE".
The docu says that the input is expected in MCASP0_ACLKX but the docu of SN65HVD78 describes the ReceiveDataInput on Pin 1 which is according to the HW-docu of the board ending in AM437X_MMC0_DAT2.
In this case the example-design will never work ...

Any suggestions ?
How to change the GPIO/Pinmux ?

Rainer

Hi Rainer,

Have you seen my first response from April 27th? I think this is what you are pointing out: "Please connect the mcasp0_aclkx signal to the "R" output of the receiver (U57, pin 1) via a blue wire. R428 and R427 should not be populated if the blue wire workaround is used."
In addition disconnect R514.

Let me know if this addresses your question.

Regards,
Thomas

Hi Thomas,

we did these modifications:
connected PIN1 of U57(SN65HVD78D) to J16 PIN31 with a wire and removed R514 but it still doesn't work ...
I don't get a signal in R31 of the PRU.


The encoder operates fine with other hardware.
I think I'm nearly at the point giving up and spend my time for looking in other solutions.

Best Regards,
Rainer

Hi Rainer,

You can check a few more items in order to find out why R31 does not show a signal.
- Check that pinmux for pru0_gpi[0] and the remaining BiSS pins is correct (see AM43xx_BiSSConfig.gel for all pinmux registers and configuration values)
- Check with a scope that that the encoder get's the BiSS signals and that the encoder provides a response

Are you checking R31 via CCS PRU register view? Note that R31 is used in 28-bit serial shift mode, i.e. bit0 to bit27 should show the current state of pru0_gpi[0].

Regards,
Thomas

Hi Thomas,

I spend some more time on it ...

What I could already notice :
- after running AM43xx_BiSSConfig.gel the settings are correct.
- when the main-application on the ARM-CORTEX is startet the BISS-settings are changed to bad ones and I can see a change in the "BISS-Signal" on the scope.
I measuring the BISS-Signal at the PIN's of J10 (between SLO+/- and MA+/-) and I'm not quite sure if this is correct ?
My scope is nort very good and I'll try to get a better scope on monday.

How is the Master-Clock generated - in the PRU-Firmware ?

Regards,
Rainer

Hi Rainer,

See my response below.

>> - after running AM43xx_BiSSConfig.gel the settings are correct.
>> - when the main-application on the ARM-CORTEX is startet the BISS-settings are changed to bad ones and I can see a change in the "BISS-Signal" on the scope.

Not sure what you exactly mean by correct/bad ones: Is this pinmux, 28-bit serial shift register input, or something else?

Can it be that the ARM application code is overwriting some PRU/pinmux register settings. You should add the BiSS configuration code from the GEL into the ARM code application code, before the ARM starts the PRU BiSS firmware,

>> I measuring the BISS-Signal at the PIN's of J10 (between SLO+/- and MA+/-) and I'm not quite sure if this is correct ?

I suggest to measure between AM437x and SN65HVD78 transceivers (i.e. U55, pin 4 and U57, pin 1).

>> How is the Master-Clock generated - in the PRU-Firmware ?

PRU is bit banging the clock signal via R30 register. If you connect with CCS to PRU, you can also manually set/clear the bit in R30 register to see if the external pin is getting toggled.

Regards,

 Thomas

Hi Rainer,
See my response below.
>> - after running AM43xx_BiSSConfig.gel the settings are correct.
>> - when the main-application on the ARM-CORTEX is startet the BISS-settings are changed to bad ones and I can see a change in the "BISS-Signal" on the scope.
Not sure what you exactly mean by correct/bad ones: Is this pinmux, 28-bit serial shift register input, or something else?

Can it be that the ARM application code is overwriting some PRU/pinmux register settings. You should add the BiSS configuration code from the GEL into the ARM code application code, before the ARM starts the PRU BiSS firmware,
>> I measuring the BISS-Signal at the PIN's of J10 (between SLO+/- and MA+/-) and I'm not quite sure if this is correct ?
I suggest to measure between AM437x and SN65HVD78 transceivers (i.e. U55, pin 4 and U57, pin 1).
>> How is the Master-Clock generated - in the PRU-Firmware ?
PRU is bit banging the clock signal via R30 register. If you connect with CCS to PRU, you can also manually set/clear the bit in R30 register to see if the external pin is getting toggled.
Regards,
Thomas

Hi Thomas,
the Master-Clock line (Output of U55) switches already to LOW wenn running the BISS-GEL script.
So this path (incl. Input-signals) should work. I'll try to set/unset it manually by writing to Register R30.
What is that bit ? I only found:
#define BiSS_CLK_BIT R5.b2 ?????

I'll measure the response of the sensor directly at pin1 U57 (which is thge same as J16, PIN31).

The main-sw modifies some settings done by the GEL-script below, i.e. 0x44E10990 !!!
I solved this by putting this code in my main-app before the PRU is started.

//#########################################################################
//Am437x BiSS Configuration gel

menuitem "AM437x BiSS Configuration"

////////////////////////////////////////////////////////////////////////////
//This section is for the pinmux configuration of BiSS firmware
////////////////////////////////////////////////////////////////////////////
hotmenu AM437x_IDK_BiSS_Init()
{
GEL_TextOut("**** AM437x_IDK Pinmuxing is in progress .......... \n","Output",1,1,1);

*((unsigned int*) 0x44E10990) = ((1 << 18) | (1 << 16) | 6); // mcasp0_aclkx for pru0_gpi[0] ==> 28-bit shift register
*((unsigned int*) 0x44E10994) = 5; // mcasp0_fsx for pru0_gpo[0] ==> BiSS MA clock
*((unsigned int*) 0x44E10a48) = 7; // gpio5[12] for enabling receive line in RS485 receiver
*((unsigned int*) 0x44E10998) = 7; // gpio3[16] for disabling transmit line in RS485 receiver

GEL_TextOut("**** AM437x_IDK Pinmuxing is Done ****************** \n\n\n","Output",1,1,1);

GEL_TextOut("**** AM437x_IDK GPIO module enabling is in progress ****************** \n\n\n","Output",1,1,1);

*((unsigned int*) 0x44DF8C88) |= 0x2; // Enable GPIO3 module
//*((unsigned int*) 0x44DF8C90) |= 0x2; // Enable GPIO4 module
*((unsigned int*) 0x44DF8C98) |= 0x2; // Enable GPIO5 module

GEL_TextOut("**** AM437x_IDK GPIO modules enabled ****************** \n\n\n","Output",1,1,1);

GEL_TextOut("**** AM437x_IDK GPIO setting is in progress ****************** \n\n\n","Output",1,1,1);

*((unsigned int*) 0x481AE134) &= 0xFFFEFFFF; // Set the direction of GPIO3 pin16 to output
*((unsigned int*) 0x481AE194) &= ~(1 << 16); // Clear the GPIO3 pin 16
*((unsigned int*) 0x48322134) &= 0xFFFFEFFF; // Set the direction of GPIO5 pin 12 to output
*((unsigned int*) 0x48322194) &= ~(1 << 12); // Clear the GPIO5 pin 12


GEL_TextOut("**** AM437x_IDK GPIO setting is Done ****************** \n\n\n","Output",1,1,1);

}

Regards,
Rainer

Hi Thomas,

I can manually toogle both signals by writing 0x00000000 or 0x00000002 to R30.
clock-signal : (U55, pin4)
and the receive-signal from encoder (U57, pin1).

But there is still no change in R31 !

Regards,
Rainer

Hi Rainer,

Some more comments/ideas:

1) The ARM needs to configure the type of BiSS encoder (clock speed, crc bits, encoder bits) by writing to the PRU0 of ICSS0 base address. Here is an example that we have used with a Wachendorf encoder.
// BiSS encoder configuration: clock_speed=1; crc_bits=8, encoder_bits=12
HW_WR_REG32(((PRUICSS_HwAttrs *)(pruIcss0Handle->hwAttrs))->baseAddr + 0x0000, 0x0001080C);
For test purpose you can also open a memory browser (ARM) and write the value 0x0001080C directly to 0x54440000.

2) Just for my clarification of the measured signal at U57, pin 1. Is this signal change then coming from the encoder, or from PRU R30 register? This pin should be actually an input to AM437x (PRU0, R31, bit 0), so any R30 change should not change the signal when the encoder is disconnected. Otherwise, please make sure that the pinmux is set to for R31 mode.

3) What is the value of GPCFG0 Register after you have run the PRU BiSS code?

Regards,
Thomas

Hi Thomas,

thanks - that helped me some steps ahead ...

1) I did this already - we have a renishaw-encoder
The settings suposed to be :
- clock_speed = ???
- crc_bits=8
-encoder_bits=32

2) The signal measured at pin1 , U57 also changes when no encoder is connected.
But I see in the signal, that the encoder is sending.
I tried several settings in the GPCFG0 Register manually - but do not know exactly what they affect.

3) The Firmware run's (with modified GPCFG0 ) now further to the other "HALT" label at the end.
The GPCFG0 is then: 0x002B02BA
The slave-error flag ist set to 0x22

Regards,
Rainer

Hi Thomas,

first of all thank you very much for your help !

Now we decided to stop the project and looking for another solution.
There are too many problems with this board.

The recent problem was that the outgoing clock-signal (PIN4 U55) was exactly reflected in PIN 1 U57).
I measured the signals directly at PIN4, U55 and PIN31,J16.
I checked the board, wirings etc. several times but didn't find a shortcut between these Pins.
I also removed R540, that didn't change the behaviour of the signals.
Maybe there is another design-error on the board or the following documentation is wrong:
Host Expansion Header - J16
31 AM437X_PRU0_ENDAT0_CLK PRU0 Data0 Clock -> might be wrong
33 AM437X_PRU0_ENDAT0_OUT PRU0 Data0 Out -> I measured this signal on PIN31
35 AM437X_PRU0_ENDAT0_OUTEN PRU0 Data0 Out Enable
37 AM437X_PRU0_ENDAT0_IN PRU0 Data0 In

Regards,
Rainer