UNIFLASH: UNIFLASH

Hi Alan,

I'll need to escalate this to the UniFlash engineer. I'll keep you posted of any upates I receive.

Thanks

ki

I will bring this thread to the attention of the device experts. They own the python script in question and can best assist further

Hi Ki,

thanks!  I'm in the process of setting up the pc (and my brain!) for python, which I haven't used before.  Thus, I should be able to run the scripts by them selves - and add more text output so I can see what's going on.  Of course, there's a level above the python that defines the parameters in the calls - hopefully I can still work it out.

Alan

Hi Alan,

Our team is looking into this and will get back to you within a few days. Please ping us if we have no answered by EOD 5/31.

Thank you,

Angie

Hi,

a little to add, which may help focus where the problem is:

I've got the mmWaveProgFlash python to more or less run by itself on the PC, and added more output - a bit like the file I attached, but I can't get it to format so nicely.  This of course has two problems:

• give my expertise with python (between zero and not much), I could have broken the original logic
• I don't have the program above this, which calls the routines (e.g. download_file in line 590), so I don't know what parameters UNIUFLASH sends over

However, what it seems to do (given the image_creator  MSTR format .bin file as input) is simply send the entire file ... un-parsed.

As I'm reading SWRA627, this is NOT what I'm suppose to do - I should parse out each meteImage, and send each one separately.  But, as said, I don't have the actual UNIFLASH calls to download_file, so I may be simply giving it the wrong file to work with.

I think there are four possibilities:

1. I don't understand SWRA627 as to how I format up each metaImage
2. I don't understand the doc as to how I split the MSTR file it metaImages (you can maybe see something of both of these in my attachment)
3. As I don't have the code above the python, maybe I'm asking it to work with the wrong file ... which may point to 2) above i.e. UNIFLASH parses out the metaImages and calls down_load_file for each
4. UNIFLASH, indeed, IS sending the WHOLE MSTR format file.  This is not what I think SRWA says to do.  If it is sending the whole MSTR file, how do I set up the FILE TYPE parameter - which the OPEN command says should be ONE of the four metaImages (SWRA table 2)?

Hope that helps!

many thanks

Alan

Hi Alan,

You should be able to send the entire image over, just broken into smaller chunks at a time. The bins are already formatted to be placed correctly in the flash. Where in the document do you see it saying it should be broken into individual metaimages?

Hi Jackson,

actually, I was starting to wonder if I'd managed to make that up!  However (i.e. how I've interpreted the words ... could be wrong): fig 2 in the imageCreator doc shows four metaImages, being for MSS/BSS/DSS/Config - then table 2 in SWRA627 talks of sending four individual metaImages, and  the OPEN command includes the metaImage ID too.  I think what I've done is interpret that to mean that the MSTR file MUST be broken out & the metaImages sent separately.

Just in case - I've already modified my code to send the whole thing over in one piece (as 240 byte chunks).  This has the same result i.e. its definitely writing, but not yet correctly.  Let's see if I can paste in the start & end of this transfer:

2: {Open to Sram} metaImage number: 1 metaImage type:4
<AA><00><13><76><21><00><04><EA><80><00><00><00><04><00><00><00><04><00><00><00><00>
3: {Write to Sram} metaImage number: 1 metaImage type: 4
chunk: 0 bin file addr: 00000000
<AA><00><F3><00><26>
<4d><53><54><52><03><00><00><00> : <37><00><00><00><a2><9c><4c><19>
<62><c8><9b><cf><80><ea><04><00> : <01><00><00><00><00><00><51><35>
<80><00><00><00><43><2c><7a><ea> : <22><4a><9f><06><78><eb><01><00>
<00><00><00><00><00><00><00><00> : <01><00><00><00><00><00><51><b5>
<00><ec><01><00><98><7a><5d><d0> : <ba><98><1a><5c><40><88><00><00>
<00><00><00><00><00><00><00><00> : <01><00><00><00><00><00><51><d5>
<40><74><02><00><41><d4><45><ef> : <6c><89><ed><12><30><76><02><00>
<00><00><00><00><00><00><00><00> : <08><00><00><00><4d><45><4e><44>
<52><50><52><43><10><76><01><00> : <00><00><00><00><04><00><00><00>
<01><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>
<3c><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>

chunk: 1342 Remainder
bin file addr: 0004EA20
<AA><00><63><09><26>
<e2><4e><7f><00><88><21><80><00> : <8e><21><80><00><88><21><80><00>
<80><21><80><00><ce><21><80><00> : <c0><21><80><00><c8><21><80><00>
<c0><21><80><00><00><00><00><00> : <ac><e5><81><00><00><00><00><00>
<0c><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>
<00><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>
<00><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>

1346: {Close to Sram}
<AA><00><07><04><22><00><00><00><04>

note I send the correct remainder, not a whole chunk ... perhaps I'll try that modification today.

Can you see anything wrong with my formatting/codes/CRC etc?  This was an SRAM load - you can see a distinct difference in loading speed between FLASH & SRAM, so I must have that bit near correct.  Also, I believe that the overall file crc IS sent for FLASH, but NOT for SRAM?

So, a critical check of what I'm sending, please: must be something fairly simple, as it's close to working, Ill have a look at adding STATUS requests during the download & see if that tells me anything.  Then three points, for my complete understanding of the protocol:

1) is it ONLY MSTR format the boot loader accepts?  I'm still wondering whether it IS possible to send e.g. DSS by itself  (would be RPRC format) .... having already loaded MSS/BSS.  Would save download time during development.  However, sending the whole MSTR does at least include the memory allocation ... not separately covered in SWRA.

In the UNIFLASH python:

2) the ERASE command seems to have a parameter for STORAGE type, which isn't in SWRA627.  Does this mean I could erase the SRAM?

3) the OPEN command (actually _send_start_download, line 423) has a "mirror_enabled" parameter. This seems to go in the reserved bytes - I know SWRA says leave these at zero, but what does it do?  I don't suppose it makes the boot loader echo what's been sent, by any chance?  That would be most useful!

Point 1) is educational for how I perform the development cycle, points 2) & 3) are for clarification - the python and SWRA don't seem to quite agree, and I'd like to send the exact correct data to the boot loader.

may thanks!

Alan

Hi again,

some progress: I've been using write to SRAM (i.e. avoiding using up SFLASH life)  but this (SWRA top of page 12) does NOT set the STATUS info, if I read that correctly.

Change to SFLASH  - ask for status after load, and I get ACK for the last data, but a reply of <00><04><33><00><33> for the CLOSE.  SWRA doesn't say what this is ,.. but the python does, its a NACK ... so it seems the loader doesn't like the CLOSE command. As below:

send:

<63><a1><9f><d1>
1347: {getStatus}
<AA><00><03><23><23>
1348: {Close to Flash}
<AA><00><07><04><22><00><00><00><04>
1349: {getStatus}
<AA><00><03><23><23>

receive:

chunk: 1342 Remainder
rxLength: 5 bytes
<00><04><CC><00><CC>
1347: {getStatus} rxLength: 4 bytes
<00><03><40><40>
1348: {Close to Flash} rxLength: 5 bytes
<00><04><33><00><33>
1349: {getStatus} rxLength: 4 bytes
<00><03><40><40>

however, a final status does seem to reply OK.

>> Now, looking at the CLOSE command - SWRA (fig 8) says it includes the STORAGE type which, here, should be 2 for SFLASH.  However, the python (line 431) send the FILE_ID, which would be 4 for metaImage1. So the python & doc don't agree. if I understand it?

Actually, I've tried both formats, and BOTH get a NACK reply ... looks like we're getting close to the problem - download is OK, but the CLOSE is wrong? (I did have an error, the checksum was wrong, but I've fixed that bit, as should be shown above).

Is the problem in the CLOSE command?

thanks

Alan

The SWRA does have some abbreviated info for simplicity. Where there is doubt, I would follow what has been implemented in the python code. Have you seen what the python file receives when it sends the close command? 

Hi Jackson,

yes, seems reasonable to use the python rather than the swra.  I haven't fully succeeded with getting info out of the python:

remember I said that the ERASE command was the only thing that appeared to be running? I've confirmed this is because, with some trace/print messages I've added - they stop the code working, rather than just not printing ... as judged by UNIFLASH stopping far too soon.  My suspicion is that when trying to print strings (e.g. the data parameter used throughout the python), something in there upsets print (ascii 00? should be null, but it's my main suspect) - same happened in c#, but I've conquered the formatting to get it all out in HEX.  Once I've got that sussed in python, I ought to be able to see exactly what's going on, without breaking it!  Importantly, I'll also be able to see just what parameters UNIFLASH is sending down to the python.

I've spent most of today re-looking at my ccs projects - getting back up to speed with where I'd got to with my own IWR code, rather than the tools, as there shouldn't be much left to get those bits working now.  I'll have another look at the python now & see if I can get the info out of it.  That should answer everything!  I'll update you once I've got that working.

many thanks

Alan

Hi Alan,

In looking at your code with the firmware team, it seems that likely the NAK is coming from the CRC being incorrect. Can you verify that you are calculating this correctly?

Also, if you are going to be modifying code in CCS, it seems simpler and much more useful to use the JTAG connection to actually debug the code. Do you plan on only loading the code fully to SRAM and not using debug mode? I think code modifications will be very difficult with this.

Regards,

Jackson

Hi Jackson,

yes, already found the CRC error (but I'll check again to be sure).  Don't think it changed anything though, still got a NAK reply. (see attachments, a couple of posts ago). I originally hard coded the message - then parameterised - but forgot to re-do the checksum to match.

I've been concentrating to day on trying to get more info out of UNIFLASH via the python: it's not easy! It's very picky about exact format - anything even slightly wrong and it either doesn't output anything, or stop that (and maybe other) bits working.  Additionally, having modified the python so I can use it stand alone (in visual studio, so break points etc available), I can get everything I want (had to change to PRINT statements) formatted quite reasonably - including getting the exact data out of it.  However, the same simply doesn't work in the UNIFLASH version. I think it's to do with trying to print any string of characters where there's an ascii value of 0 - the string thereafter (or even all of it) fails to come out.  As you can see, I've managed it OK in c# (the attachments), I can get close in stand-alone python, but not via UNIFLASH.  Any input as to how to do this would be most welcome!

So, that's why this bit is taking longer that it should.

As for modifying code - yes, while writing new code for the IWR, I'll be using CCS & JTAG, up to the point where I can see that the code compiles, runs, and does what I want.  Then, however, I'll be using the IWR a a data collection system, developing the post processing on PC.  Hence, I'll need a single tool - which can load the code (from CCS), then accept and analyse the output form the IWR.  This is not so different to what mmWaveStudio lets you do - except that I'll need full control over all the processing. If that's successful, then back into CCS to re-write the post=processing into (most likely) DSS.

thanks!

Alan

Hi,

well, I think I've concluded that I can't get any more out of UNIFLASH & the python: adding messages in SEND_PACKET (lowest level, used by all else) should give loads of output as it sends the data.  It tells me the ERASE command is sent, but no more - there is (presumably) something else in the UNIFLAHS gui that stops output during the main download.

However, between the python and what you've provided here, there ought to be enough to work out what the protocol should be doing.

What I'm suspecting now - especially as I must be close to it all working - is that my code (c# isn't particularly friendly here) is not actually hand-shaking properly.  It might look like its sending everything OK, but not all chunks are actually being passed over.  Thus, the count in the boot loader doesn't match up with the file length sent in the OPEN command - so the whole thing fails.

So - I think you've probably done everything you can, and the remaining problems are definitely in my domain, not yours, so the best thing is probably to close this thread now.

Many thanks for your help and input!

Alan

Hi,

...I thought I'd selected "resolved", at the previous reply but looks not.

I can add, then ... writing to SFLASH is now working!!  It was indeed NOT sending what it looked like it was, with some chunks missing. The SRAM variant still isn't working though, but must be VERY close.

I don't think I got it to work via changing the STORAGE type inside the python - first job tomorrow to check that.  I wonder if you've tried that?  Specifically, I'd just like to be sure that what SWRA627 (page 13) says here is correct:

1) do NOT send the overall (bin file) CRC ... you DO for SFLASH

2) once you've finished the download (0x22 CLOSE) - the IWR should be running from SRAM. No need to do anything else, no change in SOP settings etc.  I've made sure I've released the com port, but the visualiser cannot connect to either port.

thanks

Alan

Hello Alan,

1) This is correct. when sending the image to SRAM, you need to strip the 4byte CRC that is typically appended to the entire image.

2) This should be correct as well. Is this the last command sent also when you send to sflash? The sequence should be the same other than the storage command sent and the CRC from above. When you do this, is the nerror flag/LED raised by the bootloader?

Regards,

Jackson

Hi Jackson,

as far as I can see (a dangerous statement, I know!), my FLASH & SRAM code are identical, except for the command details & the CRC at the end.  Thus, if I've got FLASH to work, there seems little left to be wrong ... hopefully.

Just to state, I'm testing my FLASH down load by:

SOP5, ERASE / SOP4, Visualiser fails / SOP5, FLASH download / SOP4, visualiser straight in.  Various power cycles on the way of course.

Testing SRAM download - send the data & CLOSE, then close the com port, or simply exit my code.  As I understand it (SWRA fig 4, right hand side), the IWR should now be running - but visualiser cannot connect.

Here's a snap shot of what I send, SRAM mode (1st 2 commands are BREAK to open the com port & a PING, which I use to solicit an ACK, to start the way I've had to do the comms sequencing, to guarantee my code waits for ACK between commands.  Identical, FLASH & SRAM):

commandNumber: 3: {Open to Sram} metaImage number: 1 metaImage type:4
<AA><00><13><76><21><00><04><EA><80><00><00><00><04><00><00><00><04><00><00><00><00>

4: {getStatus}
<AA><00><03><23><23>

5: {Write to Sram} metaImage number: 1 metaImage type: 4
chunk: 0 bin file addr: 00000000
<AA><00><F3><00><26>
<4d><53><54><52><03><00><00><00> : <37><00><00><00><a2><9c><4c><19>
<62><c8><9b><cf><80><ea><04><00> : <01><00><00><00><00><00><51><35>

.....

1347: {Write to Sram} metaImage number: 1 metaImage type: 4
chunk: 1342 Remainder
bin file addr: 0004EA20
<AA><00><63><09><26>
<e2><4e><7f><00><88><21><80><00> : <8e><21><80><00><88><21><80><00>
<80><21><80><00><ce><21><80><00> : <c0><21><80><00><c8><21><80><00>
<c0><21><80><00><00><00><00><00> : <ac><e5><81><00><00><00><00><00>
<0c><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>
<00><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>
<00><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>

1348: {Close to Sram}
<AA><00><07><04><22><00><00><00><04>

Everything replies with ACK (before next command sent ... indeed you can see it pause at the start of SFLASH, some internal workings of the bootLoader, presumably)

I've also had STATUS requests in various places - doesn't seen to affect working (as in it works OK to FLASH with the STATUS requests in).  Note the CLOSE command is using metaImage type 4 i.e. metaImage1 as the parameter.

I do NOT have any error (DS1, red?) leds, just green for power & yellow for NRST.

Finally for this entry - I've edited mmwaveProgFlash so that SRAM is used throughout.  This runs & reports success .... but visualiser won't connect (uniflash closed to release com port), so same end result as for my own code.  That's why I'd be interested to know if you've tried & been successful writing to RAM?  I make no claims for my knowledge of python, and as I've failed to get uniflash to tell me anymore about what its doing, I can't exactly confirm what it really sends.

many thanks!

Alan

Hi Alan,

I have modified the mmwaveProgFlash inside of uniflash to write to SRAM successfully before. But I have only tried running this inside uniflash where the SRAM selection is not directly the single command sent. I didn't think there was another difference. TO be clear, the only differences between your load to flash code and your load to SRAM code is that you send command 0x26 instead of 0x24 to write to SRAM instead of SFLASH?

Instead of trying to connect to the visualizer (which can be a little finicky sometimes) you can also open teraterm or putty or some simple terminal to see if the COM port is active and responding. You should see a prompt and it should echo your characters.

Hi Jackson,

no, that's not the only difference:

• table 2, OPEN FILE also has the storage type in this command - and I think the python does this too (line 426 ish)
• also the CLOSE command, according to SWRA  should send the storage type - but the python sends the mataImage ID

I think I've now tried all combinations  of FLASH/SRAM codes in the OPEN & SEND commands, as well as in the CLOSE command. 

My own code started out as a terminal, so I can send commands to the IWR (in SOP4 mode).  To check, I've also used PUTTY - neither responds after my SRAM download.

I'd guess that there's something else it wants at the end of the download? Everything else is identical whether FLASH or SRAM (bar command code changes in OPEN, DOWNLOAD & CLOSE and crc), so it looks like there's something still missing that triggers the "eclipse the MMS ROM" bit in fig 4? Instead, it might be in the "Wait forever" ... but the command code differences should move to the right i.e. bootmode-UART?

If nothing else, I MUST be following fig 9 protocol, or the FLASH programming wouldn't be working.  Must be something trivial that's left - and consequently difficult to spot!

Incidentally, as a h/w check, I did get the red led on .... I went back to SOP4 to check serial comms, must have erased the FLASH and not re-sent it.  All operates as expected once I'd put the FLASH back in (my code, not UNIFLASH).

thanks

Alan

Hi,

reading fig 4 literally ....

the top right question box asks "Boot over UART Cmd".  This is the only place I can see this mentioned (SWRA & both pythons).  Page 13 Bootmode - UART doesn't mention any other commands, perhaps it's expecting the UART BOOT command to have been sent already, before the download process it talks about in this section?

Is it possible that what I'm doing is A-OK - write to SRAM.  I just haven't told the IWR what to do with it once I've sent it?

Just  a thought, because I'm running out of other ones!

thanks

Alan

There shouldn't be a specific boot via UART command needed, the bootloader should get that from the write to SRAM command.

Going through the uniflash code, the only other difference I see is that when loading the SRAM, we are reading 4 bytes instead of 1 when looking for the checksum. I am not entirely sure why this is different, but are you also doing this in your code? It is possible there is still some timing issue that is not being fully checked for?

Regards,

Jackson

Hi Jackson,

no, I didn't understand that bit either!  It goes to send_command, then to receive_packet.  It seems to be saying that the bootLoader gives different length replies between FLASH & SRAM downloads?  As far as I can see, I always get ACK reply, which is 5 byes, not 1 or 4.  Yes, I certainly could have something wrong here, but I don't know what.

What I have got - and it's in the same area - is one of the differences between sending for FLASH or SRAM.  FLASH adds 4 bytes to the file length (04ea80 for the pre-built), and this is how it decides whether to send the crc or not.  If it said something like 4 for FLASH & 0 for SRAM, I might understand it i.e. looking for the extra bytes being sent.  However, as its used in a receive_packet, it must be referring to something coming back from the bootLoader, not what I'm sending?

Timing - well fixing that WAS what got FLASH download working. When I put each command together, I give it a number. When anything is received from the com port, I report the command number ... as exists at the time of the received message.  In this way, I can see if anything is missed, or gets out of step.  I've looked through an entire transaction (FLASH & SRAM), and it all seems A-OK, nothing missed or out of order.  Each time, I get exactly 5 bytes, i.e.an ACK reply, then I send the next command, till all sent.

Where I do see a difference in reply from the loader, is in STATUS commands (e.g. after OPEN command):

• FLASH - 4 bytes, 00-03-40-40 i.e. success
• SRAM - 7 bytes 00-06-40-40-00-00-00 ... or sometimes all zeros for payload/crc, which I think is something like "thanks for asking, but nothing's happened yet"

Hope there's something there which points to what's still wrong ...

thanks

Alan

Let me check again to verify there should be no other changes. But I don't see where there could be. Can you confirm one more time, for posterity sake, that you are loading the image with the 4 byte CRC removed when loading to flash? Have you tried loading the image with the CRC also just to verify that it also fails? And the other way around (CRC stripped version loading to flash should fail). I only ask for a few more debug points to make sure the commands are for sure being sent correctly. 

Regards,

Jackson

Hi Jackson,

yes - do always ask, please!  We must be down to the level of being something trivial and obvious & thereby very difficult to find ... and all you have to go on to help me is what I send, so I'm always happy to add info.  And, as I've made my s/w show me what its doing for debug already, it's only a matter of running it and copying out the relevant bits.

To which - I've got the OPEN (includes length), SEND for the last chunck ... includes chunk length and/or not the checkSum, and CLOSE for all combinations.  Well, I haven't included the with-checkSum FLASH version ... its exactly like the SRAM one but with the code changed (26 > 24), and works.  I've also included what I've done to your pythons - which also does not work.

SRAM no checkSum:

commandNumber: 3: {Open to Sram} metaImage number: 1 metaImage type:4
<AA><00><13><76><21><00><04><EA><80><00><00><00><04><00><00><00><04><00><00><00><00>

1347: {Write to Sram} metaImage number: 1 metaImage type: 4
chunk: 1342 Remainder
bin file addr: 0004EA20
<AA><00><63><09><26>
<e2><4e><7f><00><88><21><80><00> : <8e><21><80><00><88><21><80><00>
<80><21><80><00><ce><21><80><00> : <c0><21><80><00><c8><21><80><00>
<c0><21><80><00><00><00><00><00> : <ac><e5><81><00><00><00><00><00>
<0c><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>
<00><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>
<00><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>

1348: {Close to Sram}
<AA><00><07><04><22><00><00><00><04>

SRAM with checkSum:

commandNumber: 3: {Open to Sram} metaImage number: 1 metaImage type:4
<AA><00><13><7A><21><00><04><EA><84><00><00><00><04><00><00><00><04><00><00><00><00>

1347: {Write to Sram} metaImage number: 1 metaImage type: 4
chunk: 1342 Remainder
bin file addr: 0004EA20
<AA><00><67><7D><26>
<e2><4e><7f><00><88><21><80><00> : <8e><21><80><00><88><21><80><00>
<80><21><80><00><ce><21><80><00> : <c0><21><80><00><c8><21><80><00>
<c0><21><80><00><00><00><00><00> : <ac><e5><81><00><00><00><00><00>
<0c><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>
<00><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>
<00><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>
<63><a1><9f><d1>

1348: {Close to Sram}
<AA><00><07><04><22><00><00><00><04>

FLASH, no checkSum

commandNumber: 4: {Open to Flash} metaImage number: 1 metaImage type:4
<AA><00><13><74><21><00><04><EA><80><00><00><00><02><00><00><00><04><00><00><00><00>

1348: {Write to Flash} metaImage number: 1 metaImage type: 4
chunk: 1342 Remainder
bin file addr: 0004EA20
<AA><00><63><09><24>
<e2><4e><7f><00><88><21><80><00> : <8e><21><80><00><88><21><80><00>
<80><21><80><00><ce><21><80><00> : <c0><21><80><00><c8><21><80><00>
<c0><21><80><00><00><00><00><00> : <ac><e5><81><00><00><00><00><00>
<0c><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>
<00><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>
<00><00><00><00><00><00><00><00> : <00><00><00><00><00><00><00><00>

1349: {Close to Flash}
<AA><00><07><04><22><00><00><00><04>

and the reply was:

1348: {Write to Flash} metaImage number: 1 metaImage type: 4
chunk: 1342 Remainder
rxLength: 5 bytes
<00><04><CC><00><CC>

commandNumber: 1349: {Close to Flash} rxLength: 5 bytes
<00><04><33><00><33>

NACK? says it's failed? Yes, no response in SOP4 ... and red led lit.

I'm pressing the NSRT (SW2) button between each trial - and sending BREAK to open the comms.

What have I done to python to make it SRAM (UNIFLASH 6.4.0)...

#propertiesMap['COMPort'] = 'COM37'
propertiesMap['COMPort'] = 'COM4'
#propertiesMap['MemSelectRadio'] = 'SFLASH'
propertiesMap['MemSelectRadio'] = 'SRAM'
#propertiesMap['DownloadFormat'] = True

def _send_start_download(self,file_id,file_size,max_size,mirror_enabled,storage):
storage="SRAM"

def download_file(self,filename,file_id,mirror_enabled,max_size,storage, imageProgList):
storage="SRAM"

CLOSE not changed - it send metaImage ID, not storage type

This does NOT work i.e. send, then try to talk to com port - no reply.

Hope that's everything you asked for...

thanks

Alan

To clarify, when just modifying those 2 lines in the properties map, then running through uniflash, the SRAM load does not work? This is strange as that has definitely worked in the past. Please try that with the file I included below. This is just the OOB demo for IWR6843, with the 4byte CRC removed. I only modified line 60 to set propertiesMap['MemSelectRadio'] = 'SRAM'. Otherwise I followed the standard uniflash load procedure. I was able to get a response on the enhanced UART line right after loading completed. Then when I reset the device, the response crashes, indicating that the program was running but the flash was properly erased as expected. If this is not working on your setup then there is another issue. Or did I not understand your previous message?

 https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/xwr6843ISK_5F00_mmw_5F00_demo_5F00_noCRC.bin

Hi Jackson,

thanks for the file - as a check, length 536640.  Well, that doesn't work either.  I have done just as you said, modifying ONLY the SRAM (and the com port) in the "top" python.  That was UNIFLASH 6.4.  I've done just the same with UNIFLASH 7.1.0.3796, with the same result.

In my own code, it runs through just the same as the 1843 pre-build (now exact number of 240 chunks, no remainder), and gets an ACK to the CLOSE command.  Also doesn't work.

UNIFLASH says my IWR is REV C R2101050, and the board number on the back is 6050400155.

As another check, I've put UNIFLASH back to "unedited", and programmed the FLASH.  Booting in SOP4 gives the red led - so I guess the bin file doesn't actually work on an 1843?  That said, the com port DOES echo - just doesn't do anything with it ... for the normal pre-build, if you say send a "?", it comes back with "not a valid command", or words to that effect.

Whether FLASH or SRAM, UNIFLASH does say it's completed successfully.

Hope this gets us somewhere!

many thanks

Alan

Hi Alan,

I did forget that you were using the 1843, not the 6843, so the file I sent was for the 6843. Just double checking that the file you are using is indeed and 1843 specific image AND removed the 4 byte CRC from that file? This is very curious that the uniflash modifications are not working either, I would have expected that to work without issue. I have not actually tested this on IWR1843, but the bootloader function should be the same. Can you please like to the exact images you are using and the exact part (1843 vs. 1843AOP) you are loading to?

Thanks,

Jackson

Hi Jackson,

IWR1843, NOT AOP version, files are the one you sent, or the 18xx pre-built .bin from industrial tool box (4-8-0 or 4-9-0, same content) for the OOB demo.  CRC definitely removed for SRAM.

I suspect the file contents are basically OK, as the FLASH download works .. but the problem is going to be at the level of something too obvious to see easily.

Musing: SWRA fig 4 implies the metaImages are sent BSS first, then MSS/DSS, whereas the file contents are MSS-BSS-DSS.  I can't imaging this matters, as the protocol seems to allow any order, as each metaImage is tagged as to what it is and where to put it.  I'd assume that the bootLoader sets up all the memories (i.e. store the download in SRAM), then presses START on one processor (fig 4 says MSS) which then starts everything else. Again, the order of download shouldn't matter.

There is definitely something different, though, as download (your file) to FLASH at least has something running - the com port echoes, although not processing messages correctly.  FLASH download only, not SRAM, either UNIFLASH or my own.

A similar thought: do you know what version of UNIFLASH you used before? I don't suppose someone has changed something along the way of updating it?  I haven't had time yet to try this - but I see I can download older versions from TI site.  I'll try to get to that this afternoon.

As an aside (but related): while waiting to get this bit solved, I've carried on with code development in CCS & JTAG.  I can re-build the SDK OOB (interestingly, this does NOT produce an identical bin file to the pre-built).  It takes a buit of juggling to actually get it to run - haven't quite sorted yet, I seem to have to pause & un-pause MSS ... may well be a loading-order issue I have to sort out, but then it runs & visualiser works OK.  Thus, it seems all of the dev process works OK - except for download to SRAM.

I'll let you know if I get any different out come with older UNIFLASH variants once I've had time.

many thanks

Alan

Hi,

uniflash older versions:

4 is too old, no mmWave directory & no python (that I could see)

5 is more like 6 & 7, but still doesn't work for SRAM downloads.  I've tried both changing just the "top" 2 lines, and separately putting storage="SRAM" inside each of the commands ... as I don't know what parameters uniflash sends down to them.

Has the bootLoader itself had any updates?  I can't tell you any info on this, unless there's some way of asking it what version number etc it is. Given that flash downloads are working fine (uniflash and my own code), we ought to have the majority of the protocol correct, is it perhaps pointing to something at the bootLoader end?  Either there's a missing command, or it's not doing what fig 4 says it should i.e. do the download, then it drops through to running the code.

Just to confirm - although I can't get uniflash to give me any more details as its running,  my own code lets me see that every command is returning an ACK, so OPEN, DOWNLOAD & CLOSE all seem to be being accepted.

What can we try next?  I do need this functionality for my work.

thanks

Alan