IWRL6432AOPEVM: Adding two PWM outputs and CAN to the demo code

Hi,

We are looking into your query. Please allow us a day or two to respond back.

Regards

Hello.

Aleksandr Labunskiy said:

1. The board schematic has a gazillion multiplexers. It makes very hard to track signals without breaking some other signals that are used by the code. What pins should I use for PWM? What switch positions should I set? Where will my PWM signals come out so I can make connection to them? Do I need to do any HW modifications?

You can refer to the datasheet, which shows in a tabulated form how all the different pins can be muxed.  This is a much easier view to discern than from the schematic.  In addition, SysConfig should automatically assign the pins as they are available; it will error if there are pin conflicts.

Aleksandr Labunskiy said:

2. I need one PWM signal with fixed duty cycle (DC), 50%. I need the other signal with varying DC depending on the distance to the closest object. Do I need to change any configuration default settings (#define ) in any of the files? I found a place in DPC_Execute() function when number of detected objects is calculated. I can't find a place where the distance to an object is calculated reliably. Please navigate me.

If you are tracking an object, it may be easier to use the tracks from the trackerProc DPU and use the y-coordinate of the track.  If that is the only object in the field of view and the points are all associated with that object, you could average the y-coordinate of the points in the pointcloud to get the y-distance from the sensor.

Aleksandr Labunskiy said:

3. If I want the two PWM outputs to have a different base frequency, is there any way I do that? Maybe a timer and GPIO for a fixed DC PWM? Can I use a chopper functionality of epwm to make 4kHz from 1kHz?

Yes; there is a chopper functionality for the epwm.  You can refer to the SDK documentation for more information on the API calls available to do this.

Aleksandr Labunskiy said:

4. When the above is working I want to add CAN communication to the code. Will CAN signal routing to J3 conflict with PWM or any other required signal routing (through multiplexers) on the board?

As I mentioned for question 1, you can use the SysConfig tool to easily determine a combination of pin assignments for all the modules you wish to include.  You can also refer to the datasheet for potential pin multiplexing options for a tabulated version that is easier to read.

Sincerely,

Santosh

Hello Santosh,

I believe there is some misunderstanding of my questions. I was not asking about the radar chip pin function multiplexing. I was asking about the signal multiplexing on the board through U24, U28, etc. I do use SysConfig to configure pins and I read all documentation. If the documentation could answer my questions I would not have made this post. 

The SysConfig assigned PWM function to pins E3, E4. These pins connected to several points on the board. Nothing is connected to DCA connector and FTDI chip is not powered up, so I do not have to worry about those connections. Correct? However, as I understand, pin E4 is connected to REG_MODE_SELECT signal over U24 mux (and the mux can't be switched b/c I2C connection is required). Correct? So, a PWM signal will start flipping the regulator mode very fast. Correct.? Do I need to remove R173? Do I need to make any other board modifications?

Technically speaking I do not need to track any objects. I need to know the distance to the closest object behind a moving backward machine. I believe when I enabled "CLI Removal" the tracking was removed by conditional compilation (I could be wrong). I need the code to run as a standalone, without the Visualizer. Again, what default settings (#defins, etc.) do I need to change to alter any conditional compilation you think I have to change? Please provide file names and line numbers. Where is the place in the code that I can get the distance (file, line, variable, etc.)?

Alex

Hello Alex.

Apologies for the confusion.

Aleksandr Labunskiy said:

Nothing is connected to DCA connector and FTDI chip is not powered up, so I do not have to worry about those connections

That is correct.

Aleksandr Labunskiy said:

However, as I understand, pin E4 is connected to REG_MODE_SELECT signal over U24 mux (and the mux can't be switched b/c I2C connection is required). Correct? So, a PWM signal will start flipping the regulator mode very fast. Correct.? Do I need to remove R173? Do I need to make any other board modifications?

Let me look into this and provide an update by the end of the day tomorrow.

Aleksandr Labunskiy said:

Technically speaking I do not need to track any objects. I need to know the distance to the closest object behind a moving backward machine. I believe when I enabled "CLI Removal" the tracking was removed by conditional compilation (I could be wrong). I need the code to run as a standalone, without the Visualizer. Again, what default settings (#defins, etc.) do I need to change to alter any conditional compilation you think I have to change? Please provide file names and line numbers. Where is the place in the code that I can get the distance (file, line, variable, etc.)?

Tracking is removed if CLI_REMOVAL == 1 and TRACKER_CLASSIFIER_ENABLE == 0, so even if CLI_REMOVAL is enabled, if you have the other flag also enabled it should still enable tracking.  The output of the trackerDPU(&result->trackerOutParams) contains a list of tracker objects, and this list can be used to determine the range of the closest object by looping through the list and picking the track with the smallest y coordinate.

Sincerely,

Santosh

Aleksandr Labunskiy said:

1. The board schematic has a gazillion multiplexers. It makes very hard to track signals without breaking some other signals that are used by the code. What pins should I use for PWM? What switch positions should I set? Where will my PWM signals come out so I can make connection to them? Do I need to do any HW modifications?

The EVM wasn't designed with this in mind, so your milleage may vary. The fact that the SYSCONFIG has assigned E3 & E4 bodes well however. 

The Schematics for the EVM will be key here. The best practice is to identify what signals are being used and see how they are routed. Looking at the schematics, I can see that E3 and E4 are part of the SPIA port. The next step is to look at the Mux Block Diagram, which is page 2 of the schematics. From there, we can see what the signal path will be for the SPIA port through the MUXs. The MUX BD convieniently also indicates the appropriate switch settings to control the MUXes. Further, I can see that the SPIA port MISO and MOSI connect to the J2 header port. E3->J2.6 and E4->J2.5

The REG_MODE doesn't need to be driven. If the S4.3 switch is flipped, the radar will no longer be able to control the DCDC switching mode through the Q3  FET by pulling the signal low.. The MODE pin of the DCDC's is pulled up, so therefore, this will default the DCDC to PWM mode. If you are tracking power consumption, you may see some increase in consumption, since the DCDCs won't go into PFM mode during periods of low consumption. Based on this, there is no concern of the DCDC modes flipflopping. 

The schematics are searchable PDFs, so to confirm all these signal paths for you, I just CTRL+F'ed through. I took some screen caps and tried to color code the signals to make it easier to follow. If you need to maintain other signals, than you can use this same process to determine the best path forward. 

All the images are below. First the top level MUX BD, and then a tracing of the signal path, the MUX control tables, and then finally the DCDC Mode control.

The schematics are easily located on the IWRL6432AOPEVM tool page on ti.com. I've linked it here for ease of use: https://www.ti.com/lit/zip/sprr496 

I hope this is useful and answers your MUX questions! Thanks! 

Blake

Hi Blake,

Doing what you suggested does take the PWM signals to J2 but at the same time it disconnects I2C bus from the current and temperature sensors. The demo code does not run if it can't read those sensors because of the error trap that goes into while(1) endless loop. When I2C bus is enabled through multiplexers E4 pin is connected to REG_MODE_SELECT signal. However, pin E4 is not configured in the demo code and there is no problem since FET Q3 has a pulldown on its gate.

Now, E3, E4 pins are directly connected to J9. This does not eliminate the problem with REG_MODE_SELECT being connected to PWM if I2C is enabled. This means that I either must remove R173 or somehow disable using I2C in the code. Correct? I prefer to keep the board intact. So, is there an easy way to make code run without reading sensors over I2C or it would be too many places to comment out and removing the resistor would easier?

Alex

Hello Alex.

If you want to disable I2C, you can remove that peripheral within SysConfig and there will not be any pin assigned for the I2C peripheral.

Sincerely,

Santosh

Hello Santosh,

1. Will de-configuring I2C pins also remove the code that reads the sensor sitting on I2C bus. This is what caused me a problem in the first place. When the code can't read the sensors, it goes in an error trap.

2. I am designing my own board. All following questions are HW related. I am trying to determine what connections I need from those that exist on the evaluation board.

3. I will not measure currents so I will not need current sensors. Are the external temperature sensor and EEPROM required for the radar operation?

4. I will not have debugger chip, FTDI chip, and DCA connector on my board. Will I need SPI bus for anything? It would be nice to be able to run Visualizer. I am not sure what connection it uses on the EVAL board.

5. What do I need for the external XDS prob (debugger) beside JTAG connections? Do I need to connect any the following to the prob? 

                XDS_RS232_TX, XDS_RS232_RX, XDS_SOP0, XDS_SOP1

                As I understand these would be connected over the AUX Functions cable of the prob. Correct?

6. What are the options for programming the external QSPI flash? Do I need programming points on a board for direct access to the flash? What is OK to have for Engineering use and what would be required for production?

Alex

Hello.

Aleksandr Labunskiy said:

1. Will de-configuring I2C pins also remove the code that reads the sensor sitting on I2C bus. This is what caused me a problem in the first place. When the code can't read the sensors, it goes in an error trap.

It will not; it will only remove the code that enables and configures the I2C pins.  Any I2C reads and writes in your application code will still be there.

Aleksandr Labunskiy said:

2. I am designing my own board. All following questions are HW related. I am trying to determine what connections I need from those that exist on the evaluation board.

Let us look into this and we will get back to you on the following questions next week due to an observed holiday tomorrow.

Sincerely,

Santosh

Hi Santosh,

While waiting on the answers I am working on modifying the Demo SW. As I see the Demo is set up to be loaded to RAM. I connected 5V power supply and I want the board to run as a stand along. 

1. What do I need to change in the linker.cmd file to load to flash?

2. How do I make a binary file that I can use with Uniflash APP to load SW in the QSPI flash on the evaluation board? I found a document for using Uniflash but not how to make binary.

Alex

Hello Alex.

Aleksandr Labunskiy said:

1. What do I need to change in the linker.cmd file to load to flash?

You shouldn't need to change anything in the linker file in order to flash.

Aleksandr Labunskiy said:

2. How do I make a binary file that I can use with Uniflash APP to load SW in the QSPI flash on the evaluation board? I found a document for using Uniflash but not how to make binary.

You can create a binary by compiling the demo software in CCS or building via the makefile.

Also these questions have deviated from the original topic.  Please make a new thread for any new questions.

Sincerely,

Santosh

Aleksandr, 

Aleksandr Labunskiy said:

I am trying to determine what connections I need from those that exist on the evaluation board.

Please check the HW Design Checklist https://www.ti.com/lit/zip/swrr191 

Aleksandr Labunskiy said:

Are the external temperature sensor and EEPROM required for the radar operation

External temp sensor is not required. The Radar has onboard temperature sensors. EEPROM is only used by TI UNIFLASH to identify the board and is not required.

Aleksandr Labunskiy said:

I will not have debugger chip, FTDI chip, and DCA connector on my board. Will I need SPI bus for anything? It would be nice to be able to run Visualizer. I am not sure what connection it uses on the EVAL board.

The Visualizer runs off of UART but can potentially run from SPI. Santosh can answer this question better. 

Aleksandr Labunskiy said:

What do I need for the external XDS prob (debugger) beside JTAG connections? Do I need to connect any the following to the prob? 

I'm confused? It seems like you both are and are not going to provision the debugger circuitry. Are you just moving it to another board? Please look at the HW checklist mentioned above. 

Aleksandr Labunskiy said:

 What are the options for programming the external QSPI flash? Do I need programming points on a board for direct access to the flash? What is OK to have for Engineering use and what would be required for production?

We recomend using the flashing mode on the TI chip to accomplish this. However it should be possible to flash the memory in other typical methods.

Also, I think that these new questions have moved far from the original topic of your post. For new questions such as the HW questions you have asked, please do start a new thread. Doing this helps everyone on E2E better find solutions to the questions that they have!

Thanks!

Blake