Luis is bussy with his other mod for cftbl

You sure, I thought that was nearly done?

Is he ever realy done?

Well in the 18months I owned my machine I never got full colour, machine is now sold, I’ll send the new owner here to keep a lookout for this new firmware.

I’ve a Pin2dmd in my other machine and that’s what I’ll be using in my next machine too

New firmware?
pasted_image (resized).png

Merry Christmas

Can one flash the PIN2DMD firmware on these boards?

If so, seems like an easy solution to PinballSP dragging his feet.

I am pretty sure lucky1 did have some pin2dmd firmware which ran on this hardware?

Thats true but programming the Kinetis cpu with a debugging interface is not convenient for the end user.

I have a dmdmk66 on my tftc, I have been waiting for at least 2 years or more for the possibility of being able to color my pinball machine .... Since the project I think is abandoned I hope we can install the pin2dmd firmware so we can finally have the color pinball machine. I was intending to take 2 more displays but will take pin2dmd as I put on JP. A real shame because they look good and are really Plug and Play ... But they probably don't pay off

Well, I see on his Facebook page he's starting to ship his Holomodsp for CFTBL.

He's stated on here, many times, that he'd finish the firmware once that was done.

Anyone holding their breath??!?

I hope for the sake of the buyers that the HoloModSP is a complete product, otherwise they may be disappointed down the line!

I remain very doubtful that after years the firmware is completed ...

That thing triggers on switches and is probably never realy in sinc with the game
But nice to hear he is finaly finishing something
But at least you can then enjoy his great customer service!

Guess he's not listening to us anymore. From his facebook page, in answer to a question about the HologramSP:

"Orders only to my email, I no longer connect to the Pinside forum."

Hmmm - maybe not. Some features coming in future firmware versions (e.g. Sound, ability to add your own video).

Good luck to the buyers!

*** No Longer Available ***

Sent a dm!

Hahaha, glad you switched it over to a Pin2dmd controller, this looked so promising.
With that attitude I can’t see anyone buying his cftbl mod, every owner must be on here

Because I received many questions about how to install pin2dmd on MK66 hardware here is a little info.

!!! No support from my side for this method. I will not answer any PMs about this !
I you want to play it safe just change the hardware while keeping the LED panels.

Here are two links which helped me to load my pin2dmd port on the Kinetis MK66 processor.
Remember there is no way back to pinballSP´s firmware after conversion.
I still hope that he will publish his bootloader encryption keys for easy SD based installation.
Here is adapter I used
https://mvdlande.wordpress.com/2015/10/05/cmsis-dap-on-a-cheap-st-link-v2-mini-adapter/

and here the commands I used to erase the flash
https://jcard0na.github.io/2016/11/11/recover-from-kinetis-in-secured-state.html

As far as I remember I had to issue a hardware reset at the right time to halt the processor.

I have pasted the instruction from the site.

This could be caused by a botched image running on the on-board target triggers a watchdog and asserts the reset line. In my K22 board this is visible also because the reset line is connected to an LED.

In order to fix, you need to halt the target before entering the reset state and flash it with a good image.

You can do this as follows:

If you openocd is launched on usb hotplub by systemd, disable it.

systemctl –user disable openocd-cmsis-dap.service

Attach the USB cable to the OpenSDA USB port.

Open a telnet session to openocd and issue the following commands

reset_config srst_only srst_only separate srst_nogate srst_open_drain connect_deassert_srst

reset halt
***** ATTENTION! ATTENTION! ATTENTION! ATTENTION! **** ** ** ** Your Kinetis MCU is in secured state, which means that, ** ** with exception for very basic communication, JTAG/SWD ** ** interface will NOT work. In order to restore its ** ** functionality please issue ‘kinetis mdm mass_erase’ ** ** command, power cycle the MCU and restart OpenOCD. ** ** ** ***** ATTENTION! ATTENTION! ATTENTION! ATTENTION! **** target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc

kinetis mdm mass_erase

Now you should be able to flash a new image on your target arm-none-eabi-gdb –batch –ex ‘target remote localhost:3333’ -ex ‘load freertos.elf’

I am thinking the load freertos.elf will be the pin2dmd firmware instead, lucky1 may you confirm the filename/source?

Amazon sourced debugger.

CANADUINO ST-Link V2 Compatible in-Circuit Programmer and Debugger for STM8 STM32 amazon.com link »

Lucky1 do you know the pinout references from the link to the dmdmk66 board to the pins on the dongle?

I screen captured the pinout locations on the pcb as a reference.

NOW THIS IS GETTING EXCITING
20210129_074113 (resized).jpg

And usb key locations

Screenshot_20210129-074331_Amazon Shopping (resized).jpg

Also if anyone else is reading to help get pointed in the correct direction?

https://community.nxp.com/t5/Kinetis-Design-Studio-Knowledge/GDB-Debugging-with-Kinetis-Design-Studio/ta-p/1114643

https://sysprogs.com/w/forums/topic/openocd-st-link-v2-just-hangs-instead-of-debugging/

An original ST Link debugger will not work with a Kinetis processor. Only when modified with the cmsis dap firmware like described in the link I posted above

I must also add that the latest firmware changes allowing 64 colors (V4.04) are and most likely will not be implemented in the MK66 port of the firmware.
v3.58 is the latest and maybe the last version. I must admit that I´m not very motivated to port the changes I made to that platform

Ok cool, thanks for saving us for running in circles.

I hope when i get the v2 key i will be able to make progress.

Any pointers much appreciated, hope we can post here so you do not waste any time replying to private messages about a product you do not support!!

HOWEVER, your posts here are already more support than official pinballsp.com creator.

Anyone surprised?

Totally acceptable. V4.04 sounds much more complex and should only be supported on native platform.

Just checked my magic edition board.

No debug header [email protected][email protected]

You may have to solder the pinheader

I can do that. I guess ill need to cross reference.

unofficial author history...

https://webcache.googleusercontent.com/search?q=cache:UXh7UnjRpKgJ:https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-Boot-Loader-for-SREC-UART-SD-Card-and-USB-MSD-loading/m-p/275301+&cd=13&hl=en&ct=clnk&gl=ca

Hello again.

Do not know what happen but my bootloader do not work. LED blink, I have compile and load bootloader, compile my application with linker script to 0x8000, convert HEX to binary, run uTaskerconvert to prepare and encrypt file.

I write encrypted file in SD card, put SD card in device, provide power supply, led blink, after some time I reset device but firmware do not run. Then I read SD card and I see that firmware BIN file is not in SD card, so seem that bootloader has work, read and apply firmware, because if file is not in SD card I understand that bootloader has delete it after read and write to flash.

But firmware do not work in my device. Firmware is right because of run fine when I load directly to MK66 microcontroller (compiled with original Teensy linker script). So do not understand what happen.

************

I have do one more test, my firmware file name is dmdmk66.bin, well if I put any binary file renamed to dmdmk66.bin, so not the correct firmware file but with correct name, then this file keep in SD card. I understand then that bootloader run, read SD card, look for a dmdmk66.bin file, read it, check if its correct, and if correct, read, write to flash and delete from SD card, but if file with correct name is a wrong file, then do not delete from SD card, so I understand that bootloader read and detect that file is not a correct encrypted firmware.

So, seem bootloader work, led blink and though bootloader recognize firmware file, read and delete from SD card, device do not work with firmware. May be problem is the start address 0x8000 ?, I have modify Teensy linker script to compile with start address 0x8000.

If I remove SD card, and keep device connected, led blink each some seconds. May be that device always keep in boot mode, and never jump to user application ??, I see that red led blink after some seconds, even though has delete the firmware file from SD card, and if reset device always blink again each few seconds. Seem there is no user application or never jump to it.

I have detect also that after write bootloader and run device, the Led blinks constantly, non-stop, and after put the SD card with correct firmware, then Led blink 7-8 times then stop for a few seconds and blink again 7-8 times, etc.... So Led blink change behavior after insert SD card with correct firmware file. Very strange, seem that bootloader load firmware but do not jump to user application, keep always in boot mode.

I configured source code with:
#define FORCE_BOOT() 1
#define RETAIN_LOADER_MODE() 0

Some suggestion ??

Thanks.

‎08-22-2017 05:58 PM 47 Views
mjbcswitzerland
mjbcswitzerland
Specialist V
Luis

If you have the SD card loader configured to delete the file after successfully updating it would be normal that the file is deleted - it would also suggest that the process worked.
I suggest that you check the flow diagram in http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF to check the behavior in your other test cases since this may be as expected.
In case your code is being started but doesn't run you will need to check its compatibility with the Arduino configuration - there is a list of compatibility checks in the appendix to the document and in particular for Arduino at http://www.utasker.com/forum/index.php?topic=1869.0
Also don't forget that the serial loader will normally call the application with the watchdog enabled so if the application doesn't run, disable or re-trigger the watchdog the serial loader will be re-booted to after 2s and look to be running most of the time.

Regards

Mark

‎08-22-2017 11:11 PM 47 Views
luishs
luishs
Senior Contributor I
Thanks Mark.

I suspect the problem is a reboot because of watchdog. After load firmware, led blink 7-8 times, then stop for a a few seconds, then blink again 7-8 times, and so again and again. Seem the behavior of a reboot.

How may I dissable watchdog in serial loader ??, so I will check if problem is watchdog. I do not have experience with config and control of watchdog in applications, though I understand the concept of watchdog utility to avoid a wrong working if application fail.

‎08-23-2017 06:12 AM 47 Views
mjbcswitzerland
mjbcswitzerland
Specialist V
Luis

There is usually an input that can be held to '0' (like the force loader mode input) to control whether the watchdog is enabled or disabled (useful for quick tests to verify watchdog dependency).
The Teensy 3.6 code uses

#define WATCHDOG_DISABLE() (READ_PORT_MASK(C, SWITCH_2) == 0) // pull this input down to disable watchdog (connect pin pad 23 to GND at reset)

Otherwise define

#define WATCHDOG_DISABLE() 1 // watchdog always disabled

Regards

Mark

P.S. The watchdog concept is generally the most important part of any product design. Arduino always disables it as far as I known but this is probably due to the fact that the Arduino libraries are intended for maker's projects where simplicity has priority over reliability. For professional work Arduino is a starting point but needs further development in order to achieve adequate quality.

This blog entry may highlight some important reasons to be very careful with Arduino:
http://embedded.fm/blog/2017/8/12/dont-use-arduino-for-professional-work

‎08-23-2017 01:03 PM 47 Views
luishs
luishs
Senior Contributor I
Hello again Mark.

Finally seem that work, but I do not understand what happen, why now work.

With the modify of disable Watchdog, did not work.

Then I have tried to changed the FORCE BOOT define, instead of assigning 1, I changed to assign 0, and now it works. I do not understand or I misunderstood your suggestions because of seem that must to be just on the contrary to work.

Before, not working was this to force bootloader always check SD card.

#define FORCE_BOOT() 1

Now change to this and work, may load firmware and run, my SD socket do not has SD card detect switch:

#define FORCE_BOOT() 0

At any rate I do not have tried to update firmware with a new firmware version, because of if now I put same firmware binary file in SD card, this file keep, do not delete from SD, so seem that bootloader do not update firmware if file in SD card is same version that already loaded in flash memory. Now I go to change firmware, compile, encrypt and check if bootloader load the new firmware version or if jump always to current firmware in flash.

Two questions please, to try to understand what is the real problem:

1.- It's correct that if binary firmware file in SD is same that already in flash, the bootloader do not try to load, and so do not remove from SD card ??.

2.- May be the problem is the defines of SWITCH_1 and/or SWITCH_2 ??, my board is a custom board, do not has those switches.

My current source configuration, that work at least to load firmware for first time, is this. I go to check if this configuration allow load a new firmware version or always jumpt to user application:

#define WATCHDOG_DISABLE() 1

#define FORCE_BOOT() 0
#define RETAIN_LOADER_MODE() 0

Thanks and kind regards.

‎08-23-2017 02:34 PM 47 Views
mjbcswitzerland
mjbcswitzerland
Specialist V
Luis

With FORCE_BOOT() at 0 it will load a first firmware (since the application area is empty) but afterwards it will never check the SD card and always jump to the application.

Therefore, without a switch to force the start, you MUST use FORCE_BOOT() at 1.

Regards

Mark

‎08-23-2017 03:15 PM 47 Views
luishs
luishs
Senior Contributor I
Yes, but then I do not understand what fail.

If I put FORCE_BOOT() 1 do not work, seem that load firmware but never jump to user application.

If I put FORCE_BOOT() 0 work, load firmware (at least the first time) and jump to user application.

Do not understand what is the problem, I'm becoming mad.

Why with FORCE_BOOT() 1 never jump to user application, though seem that load firmware ?. seem with this option load firmware and keep in boot mode instead of jump to user application though I have configure #define RETAIN_LOADER_MODE() 0

On the other hand I have already got the program to be written with read protection, combining source code KINETIS_FLASH_CONFIGURATION_SECURITY and with option Allow Security of Segger Jlink programmer. Need both options to write with read protection.

‎08-23-2017 04:06 PM 47 Views
mjbcswitzerland
mjbcswitzerland
Specialist V
Luis

I am sorry but I can't explain why you have this behavior. If RETAIL_LOADER_MODE() is 0 it will always jump to the application after checking the card.

As you know, the Teensy 3.6 has no JTAG debugging capability, which is why it is a very strange board to work with for real software developments (considering that it almost as expensive as a more able NXP Freedom board).

What I would do is use port inputs to control the two decisions (force boot mode and retain boot mode) so that you can more easily experiment with the effect that they have; this may show that the behavior is not exactly as initially understood.

Also consider using fnDebugMsg() (printf-like) debugging on the serial port to add some output at certain points so that you can see what decisions are really being taken and follow the complete program flow. Just ensure that SERIAL_INTERFACE is enabled and you will have output at 115200 Baud on PTD3. In fact, when using the SD card mode, there will already be some output that looks like this (example of a non-formatted SD card):

uTasker Serial Loader V1.3
============================
[0x00008000/0x00027fff]
me = mass erase
bc = blank check
dc = delete code
go = start application
> SD-card V2 - standard

Non-formatted SD-card
SD-Card not formatted
SD-Card not formatted

and then it would jump to an existing application.

Regards

Mark

P.S. Are you using the open source version from GITHUT or the supported professional version? If you are a supported user you can send the project to have it tested.

‎08-23-2017 08:31 PM 47 Views
luishs
luishs
Senior Contributor I
Hello again Mark.

Well, I've finally solved the problem, and now everything seems to work fine (tested in Teensy 3.6 and in my custom board).

But I have solved it in a strange way, I have selected FRDM_K66F instead of TEENSY_3_6, I have modified all quartz crystal values in source code, because my custom board and Teensy 3.6 works with a 16Mhz crystal instead of a 12Mhz crystal.

Also I have configure all defines for

#define WATCHDOG_DISABLE() 1

#define FORCE_BOOT() 1
#define RETAIN_LOADER_MODE() 0

Why does it fail if I select Teensy 3.6 and it works if I select FRDMK66F? I do not know, there is something different in source code, besides the frequency of crystal quartz and USB HS/FS, between selecting one or the other.

My board is a custom board with a Kinetis MK66F, LQFP 144 pin, with 16Mhz quartz like Teensy 3.6, same SDIO card schematic. Only different that I install LQFP and Teensy is BGA.

At any rate, tested in a Teensy 3.6 board, also fail when I select TEENSY_3_6, and work if I select FRDM_K66F (after modify crystal quartz value to 16Mhz), so I think something is wrong in bootloader source code to work with Teensy 3.6 when config force boot mode (load firmware but do not jump).

Hope this may be useful for another people that may have same problem. I have become mad with so many tests and source modifications, but it finally works.

Kind Regards and thank you Mark.

‎08-24-2017 01:50 AM 47 Views
mjbcswitzerland
mjbcswitzerland
Specialist V
Luis

Do you also enable USB?
The only difference that I see between the boards is the fact that one uses FS USB and the other uses HS USB. If the loader starts it will configure the USB clocks and there is a possibility that the application fails in a certain situation when one of the USB clocks has been configured but works in the other case.

By changing the USB type, different USB clocks are configured which may then operate.

Judging by the fact that you use the link address 0x8000 this is however probably not the case (USB usually uses 0x8080 in order to keep a file object at the start of Flash).

Unfortunately, not working with JTAG can make a relatively simple effect to become a big mystery that causes days of loss of time and work effort without actually being understood. Therefore I certainly advise having JTAG capability in the HW used to simplify testing/debugging and usually saving project costs (due to time loss).

Regards

Mark

‎08-24-2017 03:16 AM 47 Views
luishs
luishs
Senior Contributor I
Hello Mark.

If you refer to #define USB_INTERFACE in config.h, its disabled, and this #define is shared for both, Teensy 3.6 and FRDM_K66F.

My custom board has SWD to program and debug, though I only have test to program with Segger Jlink. For Debug I have experience with STM32 and Eclipse (OpenOCD), but I do not have yet test Debug with Kinetis, I suppose will be similar because of KDS is Eclipse based.

Kind Regards and thank you.

‎08-24-2017 01:19 PM 47 Views
mjbcswitzerland
mjbcswitzerland
Specialist V

Hi Luis

Yes, without the define USB_INTERFACE, no USB clocks will be configured and so this is not a cause.

You should be able to debug with KDS using a Segger J-Link probe. See the debug configuration, loading and debugging in the following video (from about 14:00)

Regards

Mark

‎08-24-2017 05:21 PM 47 Views
luishs
luishs
Senior Contributor I
Thanks Mark.

I will try to make Debug according to the video, so I will learn about it, because I have more future projects to do with Kinetis.

Now this bootloader already works when I configure it for FRDM_K66F, but it will be interesting to know why it fails when it is configured for Teensy 3-6.

Best regards.

‎08-23-2017 06:30 PM 47 Views
luishs
luishs
Senior Contributor I
ok, thanks Marc.

Now I'm testing with github version, and if I see that work fine, then I want order the professional version.

I have test also with Teensy 3.6 board, and happen exactly same, and also here I may see like the bootloader reboot and reboot constantly when I have compile with FORCE BOOT()1, so its not a problem with my custom board. Seem something of configuration of bootloader.

I will check source code, its very strange that work with FORCE BOOT() 0, and not with FORCE BOOT() 1. Obviously with FORCE BOOT() 0, only allow load firmware first time, so not useful, but at least I see that my firmware is correctly compiled with 0x8000 address and correctly encrypted. With FORCE BOOT() 1 never jump to user application, only load firmware and reboot constantly.

‎08-23-2017 11:13 AM 47 Views
luishs
luishs
Senior Contributor I
Thanks Mark.

I go to test it, probably problem is a reboot because of watchdog.

07-27-2017 03:22 AM 74 Views
luishs
luishs
Senior Contributor I
Hello.

Its possible use this software with Kinetis MK66 ??, I need a bootloader with micro SD card for MK66.

Kind Regards

‎07-27-2017 06:30 AM 74 Views
mjbcswitzerland
mjbcswitzerland
Specialist V
Hi

Yes, it can be used on any Kinetis part, including the K66.

Regards

Mark

‎07-28-2017 09:10 AM 3 Views
luishs
luishs
Senior Contributor I
Thank you Mark.

I have download from your Github, and do not know exactly where is the source code or example to do the bootloader with SD card for a Kinetis MK66.

May you help me please ?, I work with KDS, also with Eclipse and with Teensy 3.6/Arduino.

Kind Regards

‎07-29-2017 01:44 AM 3 Views
laibarashid
laibarashid
Contributor I
Hi Mark

I am confused and want your help , when i build my project using KDS ,

there was a .bin file in

application>uTaskerSerialBoot>KinetisDesignStudio>uTaskerSerialLoader_FLASH

, Now my point is that i want to bootload(standalone) my frdm k64f board,

what should be my next step, should i drag and drop that bin file to the

frdmboard(F ,

what exactly should i do , to get the output on teraterm like

uTasker Serial Loader

=======================

me = mass erase

bc = blank check

dc = delete code

ld = start load

go = start application

waiting for your reply Mark. I shall be very thankful, Please help.

Regards.

‎07-29-2017 07:10 PM 3 Views
mjbcswitzerland
mjbcswitzerland
Specialist V
Hi

I have created a video to answer the questions at

It shows the FRDM-K66F target being configured for UART SREC and iHEX, plus SD-Card loading.
The Binary/iHex/SREC files used are available at http://www.utasker.com/kinetis/FRDM-K66F.html to try on a FRDM-K66F board.
FRDM-K64F board is equivalent (just set the define FRDM_K64F rather than FRDM_K66F).

Attached are updated config.h and app_hw_kinetis.h files which contain the FRDM-K66F target setup for this. These are also checked in to the uTasker Open Source version on GitHb (alternatively synchronise to get them).
Supported users have these in the private developer's repository.

Regards

Mark

app_hw_kinetis.h.zip

config.h.zip

i have downloaded 2 files.

Just replace the pinball SP boards with pin2dmd boards.

I know i know.

Waiting on pcbway...

I know im being super stubborn on blowing this open, but this type of sell/abandon mentality and then leaving users hanging is unacceptable. it reminds me of Sony Playstation 3, or iPhone, when they were jailbroken wide open. I can understand if the product has support - then it must only be on official untampered firmware, but if a product is abandoned, orphaned or no longer supported, then it should be the customers decision to be able to do what they want with the hardware.

/rant

Malenko have u started playing with the 64 color modes?

Tease us to officially derail this thread?

People need to know what PinballSP has done what he's likely to do again. He only added encryption after pin2dmd firmware was loaded on his hardware. If he was smart, he would have embraced it, since it already has a color editor. Instead he adds encryption and then pretends my Godzilla colorization was done by him in his editor. Funny story, before buying a pin2dmd I thought about buying SPs solution, and when I messaged him, he said full color support was a few weeks away, and that was 4 years ago.

I don't plan to go back and redo any games with more colors, if that's what you're asking. But I have started dicking around with CB3's x-men colorization, it was already amazing before the extra colors. I'm a new dad and I honestly don't have much time to mess around. It also doesn't help that the one working Pin2DMD I have has a bunch of dead pixels on both LED screens.

Congratulations Malenko! Being a new dad must be hard in these challenging times, so thanks for taking the time for your feedback!

Everything u said about pinballsp seems to line up with other strong arm efforts by popular tech manufacturers...

If anyone can help me identify the pinouts for the swd, 3.3, and anything else necessary, that would help a lot.

20210202_085048 (resized).jpg

for swd you only need swdio and swdclk (and common ground of course). I would power the board otherwise not with the 3v3. for the mk66 maybe reset is necessary to stop the mcu, stm works without reset.
my "Luis" board picture attachedIMG_20210202_205847_1 (resized).jpg

Thanks much for the image!!

Clk
Swd
Rst
Are identified!!

T

To read up on changing my stlink to a cmsis dap and will need to understand it further...

steve45, do you know if a AVR JTAG can be used with openocd/cmsis interface?

I don't have my stlinkv2 yet, but i do have another dongle, but don't know if I can make it work with openocd, or if it supports what you did to hijack the bootloader... any direction would be helpful.

I dont think there is a cmsis dap port for that adapter

pasting in instructions linked from another website:

https://jcard0na.github.io/2016/11/11/recover-from-kinetis-in-secured-state.html

hen using openocd and kinetis-FRDM board as debugger, you might encounter this error when trying to reset your target:

*********** ATTENTION! ATTENTION! ATTENTION! ATTENTION! **********
**** ****
**** Your Kinetis MCU is in secured state, which means that, ****
**** with exception for very basic communication, JTAG/SWD ****
...
This could be caused by a botched image running on the on-board target triggers a watchdog and asserts the reset line. In my K22 board this is visible also because the reset line is connected to an LED.

In order to fix, you need to halt the target before entering the reset state and flash it with a good image.

You can do this as follows:

If you openocd is launched on usb hotplub by systemd, disable it.

systemctl –user disable openocd-cmsis-dap.service

Attach the USB cable to the OpenSDA USB port.

Open a telnet session to openocd and issue the following commands

reset_config srst_only srst_only separate srst_nogate srst_open_drain connect_deassert_srst

reset halt
***** ATTENTION! ATTENTION! ATTENTION! ATTENTION! **** ** ** ** Your Kinetis MCU is in secured state, which means that, ** ** with exception for very basic communication, JTAG/SWD ** ** interface will NOT work. In order to restore its ** ** functionality please issue ‘kinetis mdm mass_erase’ ** ** command, power cycle the MCU and restart OpenOCD. ** ** ** ***** ATTENTION! ATTENTION! ATTENTION! ATTENTION! **** target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc

kinetis mdm mass_erase

Now you should be able to flash a new image on your target arm-none-eabi-gdb –batch –ex ‘target remote localhost:3333’ -ex ‘load freertos.elf’

No news? No development for these displays? I think I'll have to keep it in 4 colors

Pinout on the TC2050 connector ( https://www.tag-connect.com/product/tc2050-idc-tag-connect-2050-idc ) should be like this

MK66 connector (resized).jpg

I managed to port the latest PIN2DMD code version (V4.30) to NXP MK66 processor used on these boards.
With this it should be possible to use all existing pin2dmd colorizations. I used a cmsis dap / daplink adapter
which is available on ebay for 6$ . Search for CMSIS DAP.

I put the software needed in a zip on my github account https://github.com/lucky01/PIN2DMD/blob/master/firmware/latest/MK66/openocd.zip
Here are the steps which I made to install PIN2DMD on my MK66 device

1. Connect your cmsis dap adapter to the device
2. Start openocd by executing "dap.bat"
3. Open a telnet session to openocd by using 127.0.0.1 and port 4444
(see putty.png)
4. In your telnet terminal enter "reset_config srst_only"
5. Connect the reset pin to ground on your device
6. Enter "kinetis mdm mass_erase"
7. Disconnect reset pin from ground
8. Enter "kinetis mdm halt"
9. Enter "flash write_image pin2dmd.bin"
10. Wait till image is fully written
11. Enter "reset"
12. You should see your device starting up with pin2dmd firmware.

These steps also replaced the encrpted uTasker loader which is originally used on these devices, with my own loader.

However if pinballSP provides the necessary parameters the pin2dmd.upd file can also be prepared for his SD card upgrade using uTaskerConvert utility.

Lucky1, appreciate your hard work on this. I will review the instructions with my stlink adapter to convert it to cmsis dap and proceed

Once again you have done great work to help out abandon-ware customers.

Screenshot_20220106-140414_Chrome (resized).jpg

is there a video of the procedure to upload the pin2dmd code to the dmd mk66? thanks

No but should be easy if you just follow these instructions

This is such great work. A big thank you for helping to support a product that isn't even yours!

Has anyone else carried out this procedure? Am am planning to do it (luckily I have electronics/embedded firmware experience) on a display fitted to a Baywatch that I have just bought as the existing colours (or lack of) are dreadful.

If I carry this out will I be able to load the PIN2DMD Baywatch colorisation?

Thanks for your help

The answer is no, because my firmware port does only support 128x32 displays and I´m not planning to invest more time into this.

I totally understand. Thanks for your reply.