Dear All
In the download page
There is the package
However if you click the Download button, no download stats. I need to support LPC1766, but it seams it is not supported by version 3 (strange because the Driver is indicated), but still I don't see any driver in version V2 for LPC1766
Thanks
Paolo
Dear Michael
Thanks for your fast replay!
I'm already using Jlink/MCU Link and MCU Link2 without any driver, to read/write variables, however I would like to add also the Application Command management (nothing more than that). I don't need any support of USB/UART/CAN ect... interface support.
" The "dreg" directory then contains drivers which do not depend on the SDK at all. The "dreg" drivers use a direct register access instead - this is basically what you need, but unfortunately again, the legacy LPC is not in the list."
With this additional limitations, do you think that dreg directory contents is enough for me ?
I read that V2 version the driver should support also LPC1766. Is it true ? Can you send me this driver?
Thanks Paolo
Dear Paolo,
the link you used to get the FreeMASTER driver is correct. Unfortunately, this driver only supports the newer devices supported by NXP MCUXpresso SDK. The LPC1766 is not supported by the SDK.
There are two options for you when using LPC1766:
- Use FreeMASTER over JTAG (Segger J-Link or LPCLink2/CMSIS-DAP) - This will enable you to inspect and control variables. No communication driver is needed, FreeMASTER accesses the memory while the MCU is running.
- Get the driver for a different part and port it to LPC1766. See more details below:
The reason for the SDK dependency is that the FreeMASTER driver layers its communication drivers on top of SDK low-level drivers. You can still get the full FreeMASTER "middleware" driver from the SDK builder link when you select one of supported MCUs, such as (e.g. MCXN947). After downloading you will find the FreeMASTER code in the middleware/freemaster directory.
Note that there are also other drivers in the FreeMASTER package (in the src/drivers), that might be partially useful to you. The mcuxsdk directory contains the primary drivers based on SDK low-level - you can still look at them to understand how the FreeMASTER driver code is structured. The "dreg" directory then contains drivers which do not depend on the SDK at all. The "dreg" drivers use a direct register access instead - this is basically what you need, but unfortunately again, the legacy LPC is not in the list. We have this kind of drivers for NXP DSC, Kinetis, Power Architecture, S12Z and S32 platforms. Porting this concept to LPC shall be quite straightforward task.
Regards,
Michal
You convinced me to use the direct JLink SWD connection without the support of your Application Command (so there is no need to port the driver to the LPC1766). However, I just discovered that I also need to support the TSA table. In fact, I want to build a configurator for my product (parameter read/write), but it can happen that the firmware in it changes version. I don't have any display to know that version number, so it is not possible to know in advance which firmware image version is loaded, which means it is not possible to load the right .AXF file in FreeMaster in advance. I need to read the address of the variables from the host processor, so unfortunately I need to port the target driver :(, unless there are other ways to work around this problem.
The only doubt I have is that you wrote:
"You can see that this simple function operates directly on UART peripheral registers. Porting this to LPC means creating similar functions which operate on the LPC UART module (which is different from the Kinetis one)."
I shouldn't need to port any peripheral communication driver (UART, CAN, USB), because I only need to support SWD. Is that correct? Can you elaborate more the porting "path trace" for only this option?
Paolo
Hello Paolo,
no, the V2 driver does not support the LPC. It supports some legacy platforms such as HCS08, HCS12, ColdFire or PowerPC, but not the LPC.
If your motivation is just to enable Application Commands, I would suggest that it would be much easier and generally a better solution to change the way how your application is controlled. Application Commands can be easily replaced by picking a few variables into which FreeMASTER writes the control request parameters and use another variable as a "request to process". Once the target application discovers this request variable set, it can process the control command and acknowledge it by resetting the request variable back to zero. This behavior is functionally equal to Application Commands, and it enables to operate over JTAG without any communication driver.
To answer your other question: The "dreg" drivers are not directly usable for you. As I wrote, the LPC is not supported, but you can create the port quite easily yourself. If you look at one of UART files such as freemaster_kxx_uart.c, you can find driver functions making atomic UART operations. For example enabling interrupts:
You can see, that this simple function operates directly on UART peripheral registers. Porting this to LPC means creating similar functions which operate on LPC UART module (which is different from Kinetis one).
Regards,
Michal