This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Csharp Interfacing to LMDFU.DLL

I've gotten my C# form to mostly work with the LMDFU.DLL library calls, however, when I try to download using the LMDFUDownloadBin function, I keep getting a

DFU_ERR_INVALID_ADDR error returned.

Here is how I set up the DLL Import:

 

 

 

 

 

 

 

[

DllImport("lmdfu.dll", EntryPoint = "LMDFUDownloadBin",
ExactSpelling = true, CallingConvention = CallingConvention.Cdecl), SuppressUnmanagedCodeSecurity]
public static extern UInt32 LMDFUDownloadBin(IntPtr LMDFUHandle,
[
MarshalAs(UnmanagedType.LPArray)] byte[] pcDataBuf,
ulong ulImageLen,
ulong ulStartAddr,
bool bVerify,
IntPtr hwndNotify);

The call is made as such:

 

using (BinaryReader binaryAppFile = new BinaryReader(File.Open(MySet.CurrentBinaryFilename, FileMode.Open)))
{
uint fileLen = (uint)binaryAppFile.BaseStream.Length;
byte[] pcFileBuf = new byte[fileLen];

 

// read the application file into memory

// read the application file into memory

 

 

 

for (i = 0; i < fileLen; i++)
{
     pcFileBuf[i] = binaryAppFile.ReadByte();
}

 

// now close the file and then process the data
binaryAppFile.Close();

 

 

IntPtr hNotify = IntPtr.Zero;

 

 

// download the binary file

 

 

eRetcode = LMDFUDownloadBin(LMDFUHandle, pcFileBuf, (ulong)fileLen, ulStartAddr, false, hNotify

);

ulStartAddr has been set by:
eRetcode = LMDFUParamsGet(LMDFUHandle, LMDFUMemoryArray);

and ready the values from the LMDFUMemoryArray.

I've manualy made changes to the fileLen value and tired to create other pointers in the place of pcFileBuf but I still get the error.

Anyone have any thoughts on what might be going on here?

18 Replies

  • Although I've never used C#, it seems that you have figured out the bindings to allow the C++ DLL to be called successfully from your program since, I presume your LMDFUInit and LMDFUParamsGet calls are working correctly. Could you let us know the actual values of the parameters you are passing to LMDFUDownloadBin and also the values returned from your earlier call to LMDFUParamsGet? The return code you quote is returned in several cases including when you pass a NULL pointer to the source buffer, when you pass an invalid value for the ulStartAddr or when the image will not fit in the flash available above the ulStartAddr you pass.

  • In reply to Dave Wilson:

    Dave, LMDFUParamsGet retrieves the following parameters: Flash Block Size: 1024 (0x0400) Number of Flash Blocks: 256 (0x0100) Top of Flash: 262144 (0x00040000) Application Start Address: 12288 (0x00003000) Paramters beting passed: LMDFUHandle: 499219200 (consistant with other calls such as handle used in LMDFUParamsGet) pcDataBuf: pointer to buffer contain the binary data to be downloaded Image length: Application start address: 12288 (passed directly from LMDFUParamsGet retrieved value) Verify bit is set false Notify handle is set to NULL Pointer I've testing with different values set for teh source buffer and binary size, I've not tested changing the ulStartAddr. I'll run some tests with different values in the ulStartAddr to see if that makes a diffrence. Thanx for your help.
  • In reply to Denis:

    Denis, You don't mention the size of the binary you are trying to flash. Given the other parameters you quote, it would have to be less than 0x3D000 (249856, 244KB) minus any reserved space you allocate (via a FLASH_RSVD_SPACE definition in the bl_config.h used to build your boot loader) to be valid. The only thing that strikes me as odd in the values you give is the start address of 0x3000. Have you modified the USB boot loader on the board you are using? By default, the start address for all our USB-boot-loader-enabled examples is 0x1800 (6KB). If you are using a standard boot loader then something is wrong here. That said, if the boot loader is set up to expect an application at 0x1800 and you try to write something to 0x3000, it should still work as far as I can remember since the address checking only ensures that you don't overwrite the boot loader itself in low flash or any sections of flash set aside as reserved space for application data storage at the top of the memory space.
  • In reply to Dave Wilson:

    Dave, Thanx for the quick response. I should have mentioned that I have been able to FLASH the application binary using LMFLash but I run into trouble when trying to call the LMDFUDownloadBin function. Yes, I did change the USB-boot-loader-enabled example so that my application starts at an address of 0x3000. Again, LMFlash, will download the binary without issue at this address. As far as the size of the binary I'm trying to upload, it's 57276 bytes (0xdfb3). I think that's well within the range you've indicated. Maybe I'll try to do another build with the LMDFU DLL with some more explicit eRetcodes to try and see which value is causing the problem. I'll let you know what I find and if you can think of anything else for me to try, just let me know. Thanx!
  • In reply to Denis:

    That's doubly strange since LMFlash (which is a C++ MFC app) uses lmdfu.dll to do the DFU updates and calls LMDFUDownloadBin to perform the operation. When LMFlash works for you, you are using the USB DFU update feature rather than JTAG/SWD? (sorry - I had to ask).

    At this point, the only thing I can suggest is that you try to step into lmdfu.dll and see exactly what is causing it to return the bad return code. The source for the DLL is found under c:\StellarisWare\tools\lmdfu if you installed in the default directory). There should be a Visual Studio project file there allowing you to rebuild the DLL easily.

    One other thing you may like to try is using your C# program to talk to a eval kit board running a vanilla boot_usb binary and see if you can download one of our boot loader example apps to that (at 0x1800). If this works, it likely rules out your app as the most obvious cause of the problem.

  • In reply to Dave Wilson:

    Dave, Yes, that was the confusion on my end. I'm in the process of working on the lmdfu test. One other note, I have been running on a system with Windows 7, 64 bit professional. I decided to try my Application on my XP computer and it's interesting that I get a an error of DFU_ERR_UNKNOWN (-4) on the XP machine. I think I'll need to step through the lmdfu code to see what's causing the issue. I'll also try your suggestions on the vanilla boot_usb binary.
  • In reply to Dave Wilson:

    Hi Dave,

    I'm still working on this issue, but another item came up in our application. In the application we're using the USB serial CDC device for USB (this is due to legacy issues.) I've written code in the application to switch from the serial CDC device to the DFU device type upon receipt of the booltoader configuration command. The problem I'm having is detecting the device automatically in my Windows application so I don't have to rely on a specific COMM port. The way I do it with the DFU device is to detcect the PID, VID and GUID, however when I try this method for the serial CDC device, I cannot obtain a handle or initialize the device (I am able to detect the PID and VID for the connected serial CDC device.) This makes me think that I may not have the correct GUID identifier. I've tried all of the GUID identifiers in the inf and the device properties but still no luck. Do you know what GUID identifier I should be looking for or am I trying to something that won't work?

  • In reply to Denis:

    Denis,

      We use different code to enumerate the serial ports and the DFU interfaces. For the serial ports, we enumerate the installed "Ports" devices then match their friendly name with the names we expect to find one of our own ports. The code to do this is similar to a source I just found on the web so perhaps this article will give you what you need.

  • In reply to Dave Wilson:

    Dave,

    Thanx! I guess I got too caught up in the examples from TI with the lmusdll that I wasn't thinking about the windows enumeration functions. I'll get those incorporated and go from there.

  • In reply to Denis:

    Dave,

    I had to do a work around on the USB serial CDC but I've been able to find the comm port by looking at the device name and extracting the COM port from the string. I then am able to set the port up using the standard serial CreateFile, WriteFile and ReadFile functions.

    Back to the DFU issue I started with. From what I can tell, the problem seems to be occurring when I start sending the binary file to my DFU device. From the usb packets, it appears that everything is being set up correctly. However, when I send the first packet of binary data to be FLASHED, my DFU device STALLS the endpoint.

    I've attached a file of exported transactions data created by my Ellisys usb monitor so you can see what is happening.

    4834.DFU binary Download.txt

    I'll still be debugging this, but anything that you may think of would greatly be appreciated.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.