OneROM

[jxx]

It is possible to add one mode equally to MODE: Standard but the Vendor ID is 0x01, so it can support one more software.

It could be done, but I think it'd break looking at the base onerom code.
None of the stock onerom tools or my flashtool would see it without modifying them.
What software do you want it to work with?

usb_descriptors.h

Code: Select all

/*
 * The MIT License (MIT)
 *
 * Copyright (c) 2019 Ha Thach (tinyusb.org)
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to deal
 * in the Software without restriction, including without limitation the rights
 * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 * copies of the Software, and to permit persons to whom the Software is
 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
 * THE SOFTWARE.
 */

#ifndef USB_DESCRIPTORS_H_
#define USB_DESCRIPTORS_H_

#define ONE_ROM_USB_SYSTEM_PLUGIN_VID 0x1209
#define ONE_ROM_USB_SYSTEM_PLUGIN_PID 0xF542

enum
{
  VENDOR_REQUEST_MICROSOFT = 1
};

extern uint8_t const desc_ms_os_20[];

#define MS_OS_20_DESC_LEN  0xB2

#define EPNUM_CDC_NOTIF   0x81
#define EPNUM_CDC_OUT     0x02
#define EPNUM_CDC_IN      0x82

#define EPNUM_VENDOR_OUT  0x03
#define EPNUM_VENDOR_IN   0x83

// Second CDC interface ("One ROM CDC Trace") - carries the PIO UART
#define EPNUM_CDC2_NOTIF  0x84
#define EPNUM_CDC2_OUT    0x05
#define EPNUM_CDC2_IN     0x85

#endif /* USB_DESCRIPTORS_H_ */

[themr.m]

I want to try with e_Ctune.. it wont connect because the vendor ID. I test with c_rome std and gold with standard mode, it can connect and emulating. The datalogging also work.

Vendor Id not the usb one, but in ostrich vendor id.

I used ostrich utility to look into one rom HW info.. as can see vendor id is 0x00 for selected software. e_Ctune software need vendor id set up to 0x01 and serial #.

These I load with e_Ctune .bin

[jxx]

i'll see what i can do.
That's the v0.1.5 flashtool, very experimental.
Does it error the same using the v0.1.4-beta from the first post of this thread?

0.1.4 was stable before I started hacking into it to get the 128K 27C010 working.
0.1.5 ended up messing with the 27C256/27C512 firmwares, it shuld still be fine and i don't think it changed anything drastic.
It may or may not have changed other things that were unintended.

I know the ostrich tool won't work, it's only a compatible communication protocol for software, not actually trying to fully emulate a moates ostrich at the hardware level.


**edit**
Well that's a rabbit hole just trying to get that software to run let alone see what it's trying to communicate to the onerom......
Basically if i can't get the software running, I can't use the debug firmware version and see what it's trying to do in order to even attmpt a fix.
Sorry but i'm not spending hours trawling thru decades old threads just to get the old software working.
If the software is simple to install and get running then I could theorectically patch any comms requests and make it answer what ever is needed.

[themr.m]

i'll see what i can do.
That's the v0.1.5 flashtool, very experimental.
Does it error the same using the v0.1.4-beta from the first post of this thread?

0.1.4 was stable before I started hacking into it to get the 128K 27C010 working.
0.1.5 ended up messing with the 27C256/27C512 firmwares, i wasn't actually testing those as i was going and only noticed it the other day randomly that it reports a different HW Info.
It may or may not have changed other things that were unintended.

I try 0.1.4 and 0.1.5. For honda ecu with difference software, so far all work fine. Not cause any static cel while running at car. Also I compare with hexeditor each firmware bin every few build, there no any difference or random change. But these tested just for 27C256 firmware build only.

[jxx]

I try 0.1.4 and 0.1.5. For honda ecu with difference software, so far all work fine. Not cause any static cel while running at car. Also I compare with hexeditor each firmware bin every few build, there no any difference or random change. But these tested just for 27C256 firmware build only.

I bench tested with HTS and CROME during developement so I know they work.
CROME in normal mode with 27C512/27C256 works, as well as honda mode 27C256, but from research I couldn't find any stock honda of the era that actually used a 64KB bin (not that I looked very hard).
HTS I found does not support 27C512 so that's why the flashtool disables it as an option, data logging the comms between the ostritch emu and HTS showed it doesn't try to access anymore than 32KB with Z mode protocol.

[themr.m]

I try 0.1.4 and 0.1.5. For honda ecu with difference software, so far all work fine. Not cause any static cel while running at car. Also I compare with hexeditor each firmware bin every few build, there no any difference or random change. But these tested just for 27C256 firmware build only.

I bench tested with HTS and CROME during developement so I know they work.
CROME in normal mode with 27C512/27C256 works, as well as honda mode 27C256, but from research I couldn't find any stock honda of the era that actually used a 64KB bin (not that I looked very hard).
HTS I found does not support 27C512 so that's why the flashtool disables it as an option, data logging the comms between the ostritch emu and HTS showed it doesn't try to access anymore than 32KB with Z mode protocol.

I dont think obd1 ecu come with 64KB file. 64KB come after people start used sst27sf512 to replace old style uv erase eprom. Because when read honda obd1 ecu oki processor, the file dump in 32KB.

And just asking, why tunerpro rt not work for address tracking, it is because tunerpro rt not detecting hardware as ostrich, or there another reason?

[jxx]

And just asking, why tunerpro rt not work for address tracking, it is because tunerpro rt not detecting hardware as ostrich, or there another reason?

What do you mean by address tracking?

[antus]

what tunerpro calls data tracing? I've also heard it called bubble tracing. Usually that's in tunerpro, but the XDF and the ADX together need to be set up for it (and each other), and you need to turn it on here.

[jxx]

About where i was leaning in thought and it needing to be setup in software files, was just after confirmation, not a fault of the emulator or data logging passthru uart.

[themr.m]

What do you mean by address tracking?

https://youtube.com/shorts/7licyJOf-VM? ... sUcofvIijn

Address tracking it like datalogging, but no additional hardware like ALDL. But it work with Ostrich or CobraRTP Motronic r6 hardware only. The function button will gray out if not compatible emulator used.



Above I try with Onerom, 27c256 , std mode and disable serial port 2. All working fine, can write and read back from onerom. Either tunerpro rt not recognize Onerom hardware or maybe it another thing not meet Tunerpro rt requirement.




Compare Ostrich and Onerom added firmware, the hardware detect difference name in Tunerpro rt. If firmware can be edit to make Tunerpro rt detect Onerom as "Ostrich II v20.9" maybe it can enable the address tracking button. But it just my theory only.