USB bootloader along with dfuprog exe

Hi Trey,

Thanks for your reply.

I havent checked the CRC thing yet as I was struggling with other issues again. For the time being, I have bypassed the CRC check, and the application runs for the model for which it wasnt working before.

1. When I tried to jump to pBootEntry I got the Illegal ISR trap. Does it mean that the pBooltEntry address is not getting resolved? Does that symbol gets erased somehow, when the application is downloaded by dfuprog? How is it perfectly managed in the bl_app example, as I could not see any special settings done in the bl_app example's project settings.

(I have called the pBootEntry() in the same way the pAppEntry() is called by bootloader. I have also taken care to import the pBootEntry symbol by keyword extern)

2. As this pBootEntry jump was giving issues, I then thought of using the soft-reset along with some flag in flash to switch between bootloader and application. I could not find any specific register related to soft-reset. Then from TI community I came to know that people use watchdog's WDCR register to reset the device by writing a non 101 value for WDCHK bits. Then I did the same thing. To test this soft-reset technique quickly I wrote the non 101 value but by mistake I did this without enabling the watchdog. From this point I started facing a big problem. Now even if I comment that watchdog section or if try downloading any other code, that code works only if it is downloaded through CCS debug and till the time it is connected in debug mode. Once I power cycle the device to run it in normal mode (without debug of CCS), it doesnt work at all. BUT, this does not happen with the bootloader code. Bootloader code works fine.

I had tried writing a good value to WDCR again with WD enabled, but no use.

I closed CCS and opened again but no use. I reset my PC, but no use. I havent tried downloading application from my colleague's PC yet.

I tried with other board as well without downloading that watchdog reset trial code. I downloaded other working code in that other board. I am now facing same issues with that board as well, even if havent tried that soft reset code on it. Is there any possibility that some setting in CCS has automatically got changed? I am feeling like handicapped as codes are not working without having them in debug mode.

Please give your suggestions urgently so that I can try tomorrow morning.

Best Regards,

Suvrat

Trey,

Thanks for your quick reply.

Yes the CRC check is bypassed for the time being only just to check if the other things are correct in general.

1. No, I havent looked at the function USBDFUUpdateBegin yet. Is it a library function or open source function? For bl_app, it mostly uses the library function for switching to bootloader so I am not able to understand how exactly it jumps. In our application we have CDC class in one model and a composite class in other model. Because of windows driver problems, we wont be able to use the DFU related functions for switching.

Also I had tried to disconnect the device from USB bus using functions - USBDevDisconnect() and USBDCDTerm(). But I dont see it getting disconnected from the bus.

2. But now I am not able to run any firmware right now without debug mode and facing the worst condition. Why it is happening you think? Is there now a permanent problem with my CCS after doing that watchdog soft-reset trial? or Controller has failed? If controller has got damaged, then why the other board is also not working? Why the bootloader code ONLY works without debug mode?

I am almost not able to work on the things right now because of this issue. How can I get the things back to working condition?

Regards,

Suvrat

I had tried that by downloading the bootloader code and erasing the flash using -c option. After using the -c option and downloading the application, it works.

But once the code gets downloaded using CCS it doesnt. The Bootloader code only works after downloading through CCS. Thats why I could erase the flash with dfuprog.

I did not try erasing flash with any other tool yet than the dfuprog.

Regards,

Suvrat

Trey,

Have you had a chance to look more at the things you were about to try yesterday?

Best Regards,

Suvrat

Yes, after thinking about it more my recommendation is to erase flash from withing CCS.  If you connect to the target, there should be an option for on-chip flash in the tools menu.  After clicking this, a box will pop up that has the option to erase flash.  Use this and it should resolve your reset issue.

BR,

Hi Trey,

Thanks for your reply.

When I tried to debug for the CRC issue, it looks that the .text section is having some problem and CRC is not matching for that section. But I am not able to find out the reason. Not able to understand that why the CRC calculation would fail?

Can you please look into this and let me know.

I have attached .cmd, .map and .hex files of my application in the attched zip file.

Best Regards,

Suvrat

Survat,

Can you send me the application's .out file?  Without this file I won't have the programs symbols and it will be very difficult to debug.  If you don't feel comfortable posting it on the forum, please email it to your FAE who can then forward it to me.

BR,

Hi Trey,

1. You might have already received the files from Pratik. Have you had a chance to debug with the files I sent? Please let me know what can be done for the CRC related issue? What changes do I need to do in the linker/code?

2. I have a question related to dfuprog 64-bit utility. Here I tested all the things using 32-bit version of the dfuprog utility (bypassing CRC check for the time being). But our customer at other location is using x64 version of the utility and he is facing some problem of "TI extension not supported". We do not have a 64-bit machine to check it. I have attached a screenshot which I received. What is the cause for this and how this issue can be resolved? It looks the same issue is not allowing to erase the flash as well.

Please let me know.

Best Regards,

Suvrat

Survat,

1. Yes, I recieved the files, but have not had a chance to work on this yet.  I'll try to get it resolved today.
2. The project probably just needs to be rebuilt.  I think you can run 32 bit apps on 64 bit machines.  Have they tried running the 32 bit version?

BR,

Survat,

I was able to recreate the issue here today, but was unable to come to a solution.  I am on vacation tomorrow, but I will pass this off to a team member who is familiar with the CRC library to see if he has any ideas while I am out of office.

BR,

Trey,

Thanks!

1. I will be waiting for resolution.

2. We have asked them to check using the 32bit version on their PC as well as on a 32-bit machine if they have one.

Best Regards,

Suvrat

Hi Suvrat,

With regards to the CRC, the .text section is 0x878b words or 0x10F16 bytes long. 

.text: algorithm=CRC32_PRIME(ID=0), page=0, load addr=003dc4de, size=0000878b, CRC=b4b088ef

The getCRCn() takes a 16 bit argument for the length (in bytes) of the block; i think that when it tries to read this value i.e. 0x878b from memory and multipies by 2 it results in a truncation of the argument. Id suggest splitting the .text section in two: .text1 and .text2, each of size less than 0x8000, and reallocate your code between them.

I realize this may not be an ideal solution but it should work. I will file an enhancement request to update the CRC routines to work with larger blocks.

Hi Vishal,

Thanks for debugging this and letting me know the workaround.

I will do that. So do I need to make change only in the linker file? Or changes in any other files are required?

Would the change be like this in linker file?

   GROUP               : > APP_FLASH,     PAGE = 0, crc_table(_CRCTestVector)
   {
       .cinit
       .pinit
       codestart
       /*.text*/

       .text1

       .text2

       /* Initalized sections to go in Flash */
       /* For SDFlash to program these, they must be allocated to page 0 */
       .econst
       .switch
   }

It would be nice if you can suggest me something, where the text section would be divided into two parts only for CRC tables i.e. in linker file. Otherwise I think it would go difficult for me to handle such text partition changes elsewhere in the code. Because I could see 2-3 occurances of .text in assempbly files. I have never divided a section into two parts ever.

Best Regards,

Suvrat

Hi Suvrat,

Suvrat Joshi said:

Would the change be like this in linker file?

yes, what you have described is correct

Suvrat Joshi said:

It would be nice if you can suggest me something, where the text section would be divided into two parts only for CRC tables i.e. in linker file. Otherwise I think it would go difficult for me to handle such text partition changes elsewhere in the code. Because I could see 2-3 occurances of .text in assempbly files. I have never divided a section into two parts ever.

Im not sure you can split .text into parts in the linker command file, atleast i dont know of a way...yet. I was thinking more about using pragmas in your C code i.e. #pragma CODE_SECTION(<function>, ".text1") and in your assembly files you will use .sect ".text1".

Hi Vishal,

Thanks for your reply.

I will try splitting text section into two.

Also it would be good if you can let me know the changes in CRC code that could be done. If the changes are not that big and if you quickly tell me the changes, I will modify the required files. Or other way is you can send me the modified files which I can replace here at the specified paths.

This way, I can proceed with the new CRC logic even if it is not released.

Best Regards,

Suvrat

Hi Trey, Vishal,

Please let me know regarding this. Waiting for your reply.

Best Regards,

Suvrat

Survat,

We are using the VCU accelerator to perform the CRC calculation.  The library for this is completely written in assembly, and will take some time to fix.  We have a bug filed and will get this fixed as soon as possible, but I cannot give you a firm date for when this will occur.  The VCU library also contains C code to perform CRC checks with the CPU.  You could try switching over to using the CPU to perform the CRC calculations to see if it has the same problems.  If it does, the CPU version should be much easier to fix since it is written in C.

BR,

Hi Trey,

Sorry for the late reply.

Would you please let me know about the VCU library? What files it contains? From where I can get those files? Which functions are required to be fixed etc.

By CPU version, do you mean to say that, I will need to copy those required functions from VCU library files to my code.

It would really be helpful if you could explain me in detail. I am not aware of all this.

Best Regards,

Suvrat

Trey,

we are also going to use the USB bootloader for our F28069U now, and we noticed too that the current one taken from controlSUITE is not working as expected.

Could you please send me (or our FAE) your already fixed version?
And when can we expect it to be included in controlSUITE?

BTW, the USB bootloader in its present form can be quite a pain to setup as a project, as it uses relative paths in its #include statements like "boot_loader/xxx" (which requires fixing when you copy it over to a new dir, but want to keep the MWare dir as an include dir for the other headers).
Also, changing the CRYSTAL_FREQ define alone (we use 10 MHz instead of 20 MHz) does not have the desired result, as the following calculations for the PLL are not depending on CRYSTAL_FREQ but use fixed values...

Regards
Felix

I also got the latest inofficial bootloader version now, and could get it to flash the controller after some struggling.

First, when ENABLE_READ in bl_config.h is undefined (which we would want to use to make reading out the whole flash not that trivial :)), flashing is not possible anymore and dfuprog.exe returns with error.
I debugged it and this is due to the switch in ProcessDFUDnloadCommand(), where it jumps to the default case as it then receives an "unknown" (possibly the now not supported read) command.
It seems verification must not be used with dfuprog when ENABLE_READ is undefined, or ENABLE_READ must be defined when using dfuprog regularly.

And I can confirm the CRC problem when using sections larger than the max. length of the getCRC32() function/macro. However, there is also a simple fix/workaround which can be implemented in the bootloader (instead of the VCU lib). Just use the CRC calculation iteratively with smaller chunks.

In function CheckCRCTable(), the CRC32_PRIME case can be replaced with something like:

            case CRC32_PRIME:
            {
            	uint32_t sz;
            	uint16 cur_sz;
            	uint16 *addr;

            	ulTemp = 0;
            	sz = 2 * pCRCRecord->size;
            	addr = (uint16 *)pCRCRecord->addr;
            	do {
            		cur_sz = (sz >= 0x8000U) ? 0x8000U : sz;

            		ulTemp = (unsigned long) getCRC32(ulTemp, addr, EVEN, cur_sz);

            		sz -= cur_sz;
            		addr += cur_sz / 2;
            	} while (sz != 0);

                if(ulTemp != pCRCRecord->crc_value)
                    return 1;
                break;        
            }

CRC works for me for large sections now.

Regards
Felix

Felix,

Glad to hear you were able to get it working, but sorry to hear you struggled.

The code that I sent you does it fact read back all the data it programmed and verifies it against the hex file provided.  I wasn't aware of the problem with the ENABLE_READ flag, and I will look into it.

Thanks for posting a workaround for the CRC issue.  Its really nice to have people that are willing to dig in and learn the software we provide.

BR,