Sensors forum

Hello Alan,

It looks like you are trying for some advanced features with the demos. Most of this is certainly possible, but I want to first back up to make sure we are on the same page.

The .bin file included with the toolbox download is complete. It shouldn't need to be parsed at all to load in uniflash. Just upload the whole image in meta image 1 slot. Uniflash will already load the image correctly. Please make sure you have followed the guide below.
https://dev.ti.com/tirex/explore/node?a=VLyFKFf__4.11.0&node=ALx6v6bosf9VTfW7lc3SHA__VLyFKFf__4.11.0 

If the goal is to write the SRAM of the device over UART, you can do this but it is not possible with uniflash without modification. To write directly to the SRAM, follow the following steps.

1. Set up uniflash normally
2. Modify the python source file to manually set load to SRAM.
   1. Open with a text editor - C:\ti\uniflash_6.3.0\deskdb\content\TICloudAgent\win\ccs_base\mmWave\FlashPython.py
   2. Uncomment lines 59-62 and input the desired COM port and device name. You could only modify the SRAM line below if desired, anything commented should default to the settings from the uniflash GUI.
   3. Use 'SRAM for propertiesMap['MemSelectRadio'] = 'SRAM'
   4. Save the file
3. Use uniflash to program the file normally
4. Note: you will need to revert the python changes if you want to load to SFLASH again. This edit will persist if you restart uniflash.

After step 4 you should be able to see the demo response on the UART lines.

Uniflash probably won't let you read memory for this device because you would want to read the external flash, which isn't supported. Is there something else that you are trying to do by reading the memory?

Regards,

Jackson

Hi Jackson,

I've been looking at this so intensely for the last few days, I've forgotten to tell you the background details, sorry!

I'm heading towards writing my own code to run on the IWR, probably based heavily on & starting from the oob code.  I'll need my own controller for this - and I don't want the com ports being already in use by say the CCS debugger.  Also, for development, I don't want to be writing to FLASH all the time.

Getting all the tools in place - I have the first part of my controller nearly done: this reads the .bin file and sends it to the IWR - either FLASH or SRAM as required.  This must be close to working, as I get ACK's and STATUS OK (when FLASH, I don't think the SRAM version sets the status) replies, but the overall download doesn't work.  That is to say, I ought to be able to download to SRAM, and the code should then start (according to the document), exactly as if from FLASH? i.e. visualiser should connect and work as before? Also, if I uniflash it correctly, then try downloading to the FLASH, it breaks it - so at least I must have enough correct that I'm actually writing to the device ...just not properly.

The attachment shows how I parse the .bin (as the doc says, so I can send each mete image separately in the SEND FILE command), plus a section of the data that it actually sends - showing full-size chunk (240 bytes), plus that image's remainder : CLOSE command : OPEN command & start of next meta image data.  This seems to tally OK with the .bin file contents and the protocol as I understand it so far, but I must have something not quite right ?

Thus, it's not UNIFLASH I'm after, I've written my own version (which will also include my own post process as I get that far): I obviously need a bit of advice to get it exactly right.

Also, as its SRAM I want to write to - is there a mechanism I could use to read it back? That would be very useful for debugging at  this stage.

many thanks

Alan

Hello Alan,

First thing, debugging is done via the JTAG port, so even if you load the code through the debugger, the COM ports are still functional and provide full interaction with the device as normal. So if you are making code changes this is the way to test them. Debugging also only loads to the SRAM, not the flash.

Alan Milne said:

I'll need my own controller for this

Does this mean you are including a controller MCU or other device on the board? Will this be loading the code in the end application? Either way, if you want to use UART to load to SRAM, the python script I pointed to above is the best starting point.

Regards,

Jackson

Hi Jackson,

thanks for the reply - and good to have the info that debugging is via JTAG, and I can still use the com ports: I'll try that, e.g. CCS compile the OOB source code & set it going de-bug wise, then see if I can still use the visualiser.

My main requirement for now is using the IWR as a research tool, with everything else on PC.  So, I'd like to download code (like UNIFLASH, but SRAM), and then configure it/get data back (a bit like the visualiser) - but completely under my control, as I'll be changing  & adding functions to the IWR code.

The link you sent seems to point to a UNIFLASH guide page, rather than any python scripts - have I opened the right thing?  Actually, something along the lines of source for uniflash (or at least the formatting & sending bits) would be very useful.

I know I'm nearly there with my own code - certainly I know for sure that I can write to the flash (and thereby presumably also sram), because I can break it*, its just not quite right what I'm writing! I've taken the document literally - sending three images, each consisting of the exact bytes & order as in the bin file. The doc doesn't seem to tell me how to deal with the shared memory, or the (bin file overall) checksum ... except that I need to send it somehow when writing to flash, although it seems not when SRAM destination.

Maybe these bits are what I'm missing that stop it working?  The file I added shows some of the exact bytes I send .. the <> notation is just to make it easier to read, I don't send the brackets.  And there's no CR/LFs either, just the pure data bytes, with the send-file protocol around it.

many thanks

Alan

* UNIFLASH the OOB pre-built .bin (SOP5), connect with vislualiser (SOP4). Use my program to write the SAME bin file to FLASH, try to use visualiser (SOP to suit)- can't connect to com ports, so I MUST be overwriting the FLASH.  

Hello Alan,

Did you look at this file? (it is in the uniflash download but does the flashing for mmWave parts). It should have the example load you are looking for.

C:\ti\uniflash_6.3.0\deskdb\content\TICloudAgent\win\ccs_base\mmWave\FlashPython.py

Regards,

Jackson

Hi Jackson,

yep, looking at the wrong thing!  Got it now - I'll look into this properly tomorrow (21:15 here now, but wanted to make progress!).

I'll reply later to let you know if this has the answers I need.

many thanks

Alan

Hi Jackson,

OK, I can see that the file allows change from FLASH to SRAM, when using UNIFLASH.  Where I need to write my own version, the other file in that directory "mmWaveProgFlash.py" looks more like it - in fact, quite a lot of it looks quite a lot like my own version, except I'm in c# rather than python.

This file is quite involved, so it'll take a little time to go through it in detail - but it looks like it is doing what I want i.e. parsing the (up to) 4 images from the .bin file & formatting/sending to the IWR?

One thing I see at a first look, is that is doesn't seem to have a remainder ... where the metaImage is split up into 240 byte sub-segments to send (or maybe I just haven't worked it out yet).  In mine, I send file/240 segments PLUS a shorter one at the end to send the remainder bytes, with the appropriate LENGTH in the WRITE command.  This is said in SWRA627 page 9 in the NOTE, but I don't quite understand the ? 1:0) part.  Am I supposed to always send 240 bytes i.e. pad out the last one to full size?

I expect it is something like that - or something else I need to send pre/post the metaImage that I've got wrong, as it IS writing to the device, just the data it gest out of what I send seems to be wrong.

In the meantime, back to trying to understand exactly what mmWaveProgFlash is doing - and see if that points to what I've got wrong.

many thanks

Alan

Hello,

I am not sure the exact details of this load. It looks like there is no remainder like you say, so likely it is just padding with 0s or the python read function is smart enough to not read beyond the end of the file. The below should be the function that reads in the end of the file on line 620. Please look at the python read() documentation.

buff = fSrc.read(self.chunksize)

Regards,

Jackson

Hi Jackson,

well, so far as I can see so far, my code and the mmWave python seem to be doing much the same, except there are one or two points I don't have the info for:

presumably the python is a part of UNIFLASH, or called by it, so I can't tell what values come down in the various parameters.  In particular, I don't know the exact file type being dealt with here.

UNIFLASH (and SWRA627 section 3.1) asks for a bin file, which is the output of image_creator, and has a header (MSTR format) plus the individual core contents (RPRC format).  Looking at what the python routines do:

send_start_download, line 423 uses a parameter file_ID. Looking where this goes in the command sent to the IWR, this looks to be the file type, which from SWRA627 table 2 needs to be one of the four possible meteImage downloads.  According to how I understand SWRA, you MUST break a MSTR file down into four sub-sections and, although it doesn't quite say so, it's implicit that each sub-section is itself a complete RPRC format file.

Now, download_file, line 590, seems to read the size - for the while file.  This might imply that it's an RPRC format file that is being read, not an MSTR?  If it is an MSTR file, then the python doesn't seem to be following the SWRA protocol, as you can't send the while lot in one go, it MUST be broken down into four metaImages?

This is important - if the python is dealing with RPRC files, then there's another level somewhere before this which parses the four RPRC metaImages out of the MSTR. Maybe this is where I've got something wrong?

I'll keep working on the python - it's obvious I've got something wrong somewhere, but so far it looks like my code and the python are doing the same things, so maybe the error is before this level.

thanks

Alan

Hi Alan,

Uniflash will load the full RPRC bin file. This should already be formatted to load straight into the flash such that the bootloader will pull from the right place.

And yes the file is running in uniflash, but you should be able to call the same functions if you extract the file. Or you should also be able to add additional debug messages to the file/log to try to understand what the data is that is being sent?

Regards,

Jackson

Hi Jackson,

As I'm using UNIFLASH (and my own code), its a image-creator file I use, which is mss/bss/dss RPRC's wrapped up into an single MSTR.

Hmm, adding more debug messages - I'll definitely try that!  Presumably these are what appears in UNIFLASH as its going - I recognise some of the text in the python file.  I don't suppose the bit of UNIFLASH which deals with unpacking the MSTR files is available by any chance?  That would let me see the whole process ... written by someone else and works.

I might also try using my code, but starting from the three RPRCs, rather than the MSTR.  That'll need a bit of extra writing, but all straight forwards. In fact, I ought really to be able to see the exact same data in the RPRC's and in the amalgamated MSTR.?  In fact, that sounds lime a easy thing to look at straight away.

I'll let you know where this gets me!

many thanks

Alan

One more thing to be sure you are aware of is the imageCreator tool that is included in the SDK. I am not sure if this is what you meant or are using?

C:\ti\mmwave_sdk_03_05_00_04\packages\scripts\ImageCreator

Since you say you have the 3 images in RPRC format, not .xer4f format from CCS, you may have already been using this. BUt just want to make sure you are aware of the tool, user's guide, and provided scripts. (it is generating, not unpacking, but it should help)

Hi Jackson,

yes, the supplied imageCreator is what I mean - as used by CCS when producing the overall .bin file. That is to say I'm not actually using imageCreator myself, but using its output, as part of CCS.  Thus, somewhere in UNIFLASH, it must be unpacking into the three separate metaImages.

This is where I've started with my own code, as it seems simplest to use a single file as its input. To be complete, this is custom code I have written from scratch, using SWRA627 as my guide ... although, obviously, there's something not quite right yet!

I've looked at adding output text into the python scripts.  Interesting: I can modify the messages around the ERASE part, I can even make it show my that its sent a packet, which is the erase command.  What does NOT happen, is any output from the OPEN (0x21) or SEND (0x24 or 0x26) parts.  So, it looks like this is NOT the code UNIFLASH is using?  One thing still to try, is to send using an RPRC format file as UNIFASH input (e.g. the DSS part).  Given that UNIFLASH has four possible input files, and the protocol allows four metaImages, then this seems like a possibility.  This MIGHT use the python code, in which case I'll be able to get more information out of it, and see what its doing - and be able to compare with my code.

One point of feedback: when I change the COM port & SFLASH to SRAM, as you suggest, UNIFLASH doesn't show this, the SETTINGS page still just says COM1 & SFLASH.  However (without changing anything in UNIFLASH), it does open the right COM port, as set by the python.  So, even though it might not look like the python changes have worked - it seems they have.

I'll let you know if sending an RPRC file gets me any further.  However, given that it seems that this is not the code UNIFLASH is using with MSTR files ... do you know of any other python I could look at, to see what its doing?

many thanks

Alan

Hi Alan,

It is likely that the debug statements you add to those python scripts just aren't printing in the right place. You may need to add your own log file and write to that file in those scripts. Its a little clunky but it should work. Otherwise look at some of the other print statements in that file and see where they go. Likely it is printing to a log file rather than the console. There are a couple other log files in uniflash, you can see where these are being stored from the settings menu.

As you indicate, the code in those files is certainly being run. You can change the code and the behavior changes. So it seems to just be not in the right scope to print to the uniflash console. You are also right that the changes to com port and sflash don't really reflect in the GUI. This is known and because we are essentially hardcoding those values in the script rather than using the GUI declared values.

This is the best example of code load via UART. Can I ask why exactly you need to recreate this functionality? I thought you said this was just for code development?

Rgards,

Jackson

Hi Jackson,

yes, I did have some issues getting new messages to appear - and did indeed copy ones that worked in other parts of the code.  I'll look for log files to be sure what they may contain.

I have tried RPRC style files (from CCS) in UNIFLASH - and they definitely do not work ... I thought there might have been the option.  If you look at line 99 of the mmWave python, you'll see MSTR" being put in the local header structure.  As yet, I haven't managed to decipher the python around reading out the bits from within the MSTR format - there should be something which locates the start (addresses in the MSTR header) of each RPRC section.  Must be there somewhere!    At the moment, it looks like line 590 download_file reads & sends the whole file in one go ... that's not what I think SWRA627 is saying to do.  That's exactly why I'd like to get it to produce some more outputs, so I can see what its doing.

Why am I doing this? Yes code development, but I'd rather like to end up with a single tool which does everything: program the device (like UNIFLASH but SRAM); configure (e.g. visualiser ... indeed the bit I did first, sending the config files); collecting data & various post-processing (e.g. visualiser + matlab).

As I will do quite a lot of post-process development on the PC, in this tool, I'd rather have knowledge of & control over the whole process of interacting with the IWR.  If the research work (the radar bit is the real front end of my innovation) turns out to work, then I'll look to putting more of the processing into DSS.

Speaking of which (and definitely all part of the same question thread), how much freedom is there in downloading code onto the IWR? The protocol includes the number of metaImages, so could I:

• send JUST, say DSS, and not the other two (assume they're already in there)?
• if more than one image, does the order matter? Does it HAVE to be MSS-BSS-DSS?
• does the order in the MSTR file matter?  Each image has an ID for which processor its for, so does say MSS HAVE to be metaImage_1?

These are just for completeness of understanding of the protocol - I won't be re-writing any MSTR files from CCS & imageCreator!

Right ... log files ...

many thanks

Alan

If you are using the bootloader over UART, you should be able to load single metaimages. I don't think you will be able to load just the DSS part of an image. Because if you are not loading from flash, then nothing will be in the memory at startup. You will need to load the entire image. More flexibility is given when loading JTAG since you can load individually to the cores at runtime.

Regards,

Jackson

Hi Jackson,

I haven't had much luck with log files - I can switch them on & download, but doesn't seem to be very much in them.

I'm wondering - is there some difference in how you get messages out, depending on where you are in the code?

I've tweaked the mmwave python so that, for the erase function (only one I've managed to add output messages to), so that it adds the string ERASE to the call to _send_packet which then tells me that a packet was sent, and it was ERASE that called it.  Using the exact same message format inside the download_file routine does nothing.  My added message code is like this:

self._trace_msg(TRACE_LEVEL_INFO, str("---->Send packet2 data= %s" %(typeString))) ... or just with a "string of letters" inside the last brackets

I note that the send_packet has an _ in front ... does this change how the trace_msg works?

thanks

Alan

Hi Alan,

Uniflash is supported by another group. For the debug and implementation of the scripts within the uniflash tool, I suggest you open another post about uniflash as it should get you to someone who can help more. 

If you are trying to run this standalone, you should be able to run the python functions directly from your PC, outside of uniflash. Have you tried this? This would be more similar to your desired implementation. 

Regards,

Jackson

Hi Jackson,

This is the first time I've done anything with python, so I don't know what tools I'd need, or if they're already somewhere on the pc.  I'll have a look at starting a new thread based un uniflash, and close this one once that's started up.

many thanks

Alan

Hi Alan,

You will need to download python, should be easy to install. I don't know what packages you will need for the uniflash scripts but it should say at the top.