Mity CPU Platforms » ARM9 Based QNX Platforms

You will probably need to modify the omapl138_psc_init() to include a line like:

omapl138_psc_enable (PSC_MODULE_UART2);

Hope this helps.

We aren't having any luck, John will try to call, and we've sent along the files.

Mark,

Please send you pinmux (both the .pin and the .h files) and startup script files. You can just attach them to a forum message reply using the Files and Add another file links.

The startup script files will need to make sure that the clock speed on both of the enabled devc-ser8250 lines have the same -c option (specifies the clock speed)

Do you know what revision of the indio board you are using?

Thanks.

John

Here is a snapshot of my last attempt (attached)

Devices configured:

EMAC (RMII)
EMIFA/EMIFB
MMC/SD1
UART0,1,2
SPI0 (SCS 0 and 1 only as 2-5 collide with UART 0)
SPI1 (SCS 0 and 1 only as 2-5 collide with UARTS 1&2)
I2C0
There are a few GPIO pins added to the mix, not sure what for: GP0[1,2,3,4,6,7,13,15], GP6[12,13,15]

It may be more of a hardware problem - we have the industrial IO board 80-000268RI-2 serial 110759 and we see no RS-485 signal out of J504 that makes any sence. We've also tried Linux and failed to get output there too.

Mark,

I did not understand the details of uart 2 on our kit before. As I understand it now, it is connected as a half-duplex RS-485 interface. If you are expecting to see rs-232 serial port activity, this is not going to work. If you are expecting RS-485 signals, then there is hope.

There is an additional GPIO line that serves as a transmit-enable for the half-duplex interface. This is GP0⁸. (bank 0, offset 8) I believe this line needs to be set in order to transmit anything. The regular devc-ser8250 doesn't know anything about this line.

In order to drive the gpio lines, you will need to change the pinmux to include gp0⁸. (use the gpio line instead of UART2_CTS) In the *.bsh file, there is a line with gpio-omapl1xx which can be used to drive gpio lines. The gpio-omapl1xx driver takes arguments of the form -p out=gp<bank>p<pin>@<name>:<value> where:

• bank is the gpio bank number. In this case, the bank is 0
• pin is the pin or offset number. In this case, 8
• name is the desired name of the "device" in /dev. If you don't use the @name, the name will be /dev/gp0p8. Or use a name of your choice.
• value is the initial value, 0 or 1.

For testing purposes, you should be able to set the gpio pin, try transmitting, and then see activity on the lines.

For real operation, the use of the gpio line needs to be tied to the beginning and end of transmissions. This may be easy to do within your application, or you may want a modified devc-ser8250 driver. (needs to know the line is half-duplex and has a gpio line available to enable transmit.)

Hope this helps.

We were able to toggle other GPIO lines that come out the connectors on the back, but unable to see any activity with GP0⁸, nor GP1² or GP1³, or in fact any pin on J504.
We are using a scope to look at the pins.
I've tried all the various combinations of disabling UART2 and enabling the GPIO pins.
It appears that the industrial IO board / dev kit wire the SOM directly to J504 - what, if anything is between the L138 and the edge connector on the SOM?
I've also tried Linux and I'm unable to get the port working there.
Do you have any code sample that outputs to the port?

Mark,

I do not know of any qnx code that has been used with this port. I have been talking with the hardware guys and it seems that this port is an expansion port. This means there needs to be additional hardware added depending on what kind of output you intend to use. For example, if you want RS-232, the signal levels are TTL so something needs to be done to change the levels to something appropriate for RS-232. (I am a software guy so if this explanation does not make sense, please forgive me.) There also needs to be something done if 485 signals are needed.

There have been different revisions of this port. We used to have an isolation circuit on the board that also produced 485 levels but now, the signals come directly to the J504 port. This means you can run the lines to something that will produce RS-232 level signals, or you can run the lines to something that will produce the 485 signals.

What is your intended usage for the port? RS-232 or RS-485?

Assuming RS-232, the items that need to be taken care of in order to use the port are:

• Run a ribbon cable to some hardware that will change the signal levels to RS-232.
• Change the pinmux to include the UART2 RX and TX lines. It looks like your file does this.
• Change the bsp-mitydsp-omap-l138.bsh file to enable Uart2. It looks like you have done this.
• Change the omapl138_psc_init() function in init_hwinfo.c so that the first few lines look like:
  

  void omapl138_psc_init(void)
  {
      // Enable the resources we need - can disable unused things here to save power
  
      omapl138_psc_enable (PSC_MODULE_EMIFA);
      omapl138_psc_enable (PSC_MODULE_UART1);
      omapl138_psc_enable (PSC_MODULE_UART0);
      omapl138_psc_enable (PSC_MODULE_UART2);    // This is the new line
      ...
  }
  

  • Please double check that this has been done.

You should not need the transmit enable line (GP0⁹) in order to use RS-232 output. I think I had fat fingers yesterday. The GP0⁸ should have been GP0⁹. This is the transmit enable for the port. Sorry for the mistake.

If the intended usage is 485, then GP0⁹ will also need to be added to the pinmux and a way of driving the pin when needed would have to be added.

Sorry for the confusion, hope this helps.

John

We are using RS-232 at TTL levels, so that is not a problem.
We had done all the steps you outlined and we are not seeing output from the pins using an scope.

Mark,

I have tried using a scope on an INDIO board (80-000268RI-2 rev. B, serial number 110765) with a module (L138-FG-225-RC, serial #110441) and have the following results.

What I did:

• Started a new workspace
• Imported the qnxbsp-20110629.zip bsp
• Loaded the pinmux_indio.pin file into the pin setup program.
• Added UART2. Turned off the i2c1 pins that collided with TX and RX.
• Saved the settings into the pinmux_indio.pin file
• Saved the settings into the pinmux_indio.h file
• Modified the init_hwinfo.c to include a omapl138_psc_enable (PSC_MODULE_UART2); line in the omapl138_psc_init() function.
• Modified the bsp-mitydsp-omap-l138.bsh file to uncomment the lines
  

  devc-ser8250 -u4 -M -e -F -S -b115200 -c150000000/16 0x01d0d000^2,61
  waitfor /dev/ser4
  

• Modified the bsp-mitydsp-omap-l138.bsh file to comment out the lines
  

  #display_msg Starting I2C1 Services
  
  #i2c-dm6446 -a0x2 -i51 -p0x01e28000 -f24000000 -l0x1000 --u1
  #waitfor /dev/i2c1 10
  

• Use File->Save All to save all the changed files
• Build the bsp-mitydsp-omap-l138 project
• Open the System Builder perspective to start the tftp server
• Open a terminal view, connect to the board on serial port 1
• Turn on the board, stop at a u-boot prompt
• Type dhcp to get an ip address
• Type run bootqnxtftp to download and boot the qnx image
• At the qnx prompt, verify that /dev/ser4 exists
• Type ls -l /proc/boot >/dev/ser4
• Attach the ground of the scope probe to TP1 which is on the edge of the board close to the "l" in Critical
• Put the scope probe on pin 6 of the Expansion port connector. Pin 6 is the pin closest to the TP1. Also closest to the letter "E" of Expansion Port.
  • TX is on pin 6, RX is on pin 2
  • TX_ENB is on pin 1
• When nothing is going on, the probe seems to show a level of about 3.3 volts.
• When the ls command is repeated, there is a flurry of activity on the scope as the characters are being output.

As an additional test, tried setting up access to the TX_ENB via the GPIO bank 0 pin 9. This involved the following steps (with a couple of mistakes along the way)

• Execute gpio-omapl1xx -p out=gp0p9@tx_enb:1 & to start the gpio driver and create a /dev/tx_enb device file.
• cat /dev/tx_enb to see that the current value is 0
• Put the probe on line 1 and see that the level is 0
• echo 1 >/dev/tx_enb to set the level to 1
• Nothing happened on the scope line
• I realized I had not turned on the pinmux for gp0 pin 9.
• Changed the pinmux, saved the .pin and .h files
• Rebuilt the qnx image
• Rebooted the board
• Tried again, same result.
• Noticed that the initial value for tx_enb should have been 1, not 0.
• Realized that just changing the pinmux_indio.h file may not cause a rebuild.
• Did a project clean
• Rebuilt the project
• Rebooted the board
• Tried again, now it works. The scope on line 1 tracks the state of /dev/tx_enb.

If you haven't done a clean and a rebuild, please do so. Momentics is nice in a lot of ways but catching dependencies and the need to rebuild is not one of them.

Please let me know how your steps are different from these.

Hope this helps.

John

Just saw a signal out of the port - thanks. It may have been a conflict with the I2C or something else we tried along the way that broke it. Either way this was a big help - thanks.