VisualGDB different behaviour as LPCExpresso

[bossssie]

Hi everyone,

I just bought a license for VisualGDB an I am now in the process of using my projects to visual studio. (LPC1346)

Now i get a strange thing I cannot figure out. I have an example project in lpcexpresso called usbd_rom_cdc, this works great on my board with the lpc-link. If i copy this project to use with visualgdb and a j-link it builds without any problems but I get no devices in device manager, while in lpcexpresso i get a com port with my board.

I checked startup files and config files but everything seems to be the same.

Does anybody have any idea what could cause this problem and how to solve it?

Bossssie

[support]

Hi,

No problem, we can help you track this down, however we would need some clarification from you first.

Is the project that works built with the GCC compiler under a different IDE, or is it using a completely different compiler (e.g. IAR)?

If it using gcc, we would advise using Embedded Memory Explorer to compare the 2 ELF files (see this tutorial). Specifically, check if there are some symbols that are only present in one project, but not the other one, and also check the addresses of main() and some global variables (they will be different, but should be located in the same memory region for both ELF files). Also check if the project contains board-specific code for clock setup (e.g. PLL, clock divider, etc) and ensure both projects use the same settings.

[bossssie]

I use LPCExpresso as an comparison and that uses GCC.

I tried comparing the ELF files, I loaded the LPCExpresso .axf file in visual studio (is this correct).

It looks like it’s completely different and I don’t get too much information from it. Snapshot is in the

As far as I looked in the startup code it seems to be more or less the same. Crystal setup is also exactly the same.

 

 

 

Attachments:

You must be logged in to view attached files.

[bossssie]

Ok as far as I can find out is that it doesn’t like this call in visualGDB USBD_API->hw->Connect(g_hUsb, 1); This should pull up the resistor on the USB datalines. It looks like visualgdb doesn’t process this call correctly.

/**
* \brief Hardware API functions structure.
* \ingroup USBD_HW
*
* This module exposes functions which interact directly with USB device controller hardware.
*
*/

 

/** \fn void Connect(USBD_HANDLE_T hUsb, uint32_t con)
* Function to make USB device visible/invisible on the USB bus.
*
* This function is called after the USB initialization. This function uses the soft connect
* feature to make the device visible on the USB bus. This function is called only after the
* application is ready to handle the USB data. The enumeration process is started by the
* host after the device detection. The driver handles the enumeration process according to
* the USB descriptors passed in the USB initialization function.
*
* \param[in] hUsb Handle to the USB device stack.
* \param[in] con States whether to connect (1) or to disconnect (0).
* \return Nothing.
*/
void (*Connect)(USBD_HANDLE_T hUsb, uint32_t con);

As far as I understand the code this calls a precompiled USB function? In LPCexpresso this is working correctly in visualgdb not.

[support]

It is hard to say why the VisualGDB project would not call this function as our BSPs contain the code from the original SDKs and do not introduce any changes beyond trivial bugfixes.

That said, it should be relatively easy to narrow it down. Please try replacing the ELF file generated by VisualGDB (<Project directory>\VisualGDB\Debug\<Project Name without Extension>) with the ELF file generated by the NXP IDE. Then select Tools->Options->Projects and Solutions->Build and Run->When Project is out of date -> Ask. Finally, start a new debug session and don’t rebuild the project. This will launch the ELF file produced by the NXP IDE using the VisualGDB’s debugging logic. If this results in a usable USB device, the problem happens at the build stage.

In that case, please try setting a breakpoint on the code responsible for calling the Connect() method in both projects and try comparing the behavior. If debugging the original ELF file under VisualGDB doesn’t work, please check if using the “Program and start without debugging” works for the original executable and for VisualGDB-based executable.

[bossssie]

Ok so debugging the NXP ELF file with VisualGDB works so nothing wrong with the debugging part.

But now I’m stuck again, i checked register addresses and they seem to match up. So I’m stuck again.

I’m sorry I am a hobbyist and not an expert in this kind of problem solving. If you have any more pointers please let me know.

[support]

No problem. Unfortunately, there is no easy solution here, as it looks like different versions of the NXP framework (or the sample project itself) work differently.

The solution would be to extract the build command lines used by the NXP IDE, build the project manually using those command lines and then try combining them with the VisualGDB command lines (e.g. using VisualGDB’s linker command line to link the object files produced by the NXP IDE or vice versa). By checking the behavior of the build results, you should be able to pinpoint a specific source file (or a compiler/linker flag) that is causing the issue. Unfortunately, it would take several iterations to nail it down (you can check this tutorial for a similar process for the Keil compiler).

Another option would be to import the NXP project into VisualGDB as an externally built project (using NXP’s Makefile and NXP’s driver libraries). This will allow reusing the existing build system (that produces usable projects) with the rest of the VisualGDB’s features.

[Author]

Posts